JEP 343: Packaging Tool
kevin.rushforth at oracle.com
Wed Jun 5 21:20:28 UTC 2019
Thank you for your detailed review of jpackage. Given that RDP1 is only
a week away, I agree that we don't have time to address your feedback.
Either Andy or I will move it back to "Candidate" and then proceed as
On 6/5/2019 2:16 PM, mark.reinhold at oracle.com wrote:
> I saw that you moved JEP 343 to “Proposed to Target,” so I spent a
> couple of hours looking at it. You’ve made good progress but I don’t
> think this is in the “nearly finished” state that we ask of features
> in the six-month cadence. I suggest that you move this JEP back to
> Candidate for now and continue refining it. The next feature release,
> JDK 14, is just six months away.
> Some specific observations and suggestions:
> - At the moment there are 75 open issues in JBS , 69 of which are
> P3 or higher. JDK 13 will enter RDP 1 next week, so there’s not
> much time to make progress on all those issues.
> - The use of the term “installer” in the JEP and in the command-line
> options is confusing. The tool only creates installers on Windows
> and macOS (pkg); the other formats that it supports (macOS dmg,
> Linux deb/rpm) are OS-specific packages rather than interactive
> installers. Consider replacing the term “installer” with “package”
> throughout. This would also align better with the name of the tool
> - It’s not clear why there are distinct subcommands to create an image
> vs. to create an OS-specific package. Given the name of the tool,
> I’d expect creating a package to be the primary behavior. An option
> to preserve the image, which is just a temporary result, could make
> sense, as well as another option to skip the creation of the
> package, but I don’t understand the need for subcommands.
> - On a Debian machine I tried to create a package from a trivial,
> two-module application using the command
> $ jpackage create-installer -o /tmp -p lib -m org.openjdk.hello -n hello
> This terminated with exit code 255 and an error message. In Linux,
> and Unix/POSIX generally, an exit code of 255 means that the exit
> status was out of range. I suggest you exit with the value 1 on
> errors, at least on Linux.
> - The error message from the above command was:
> Bundler RPM Bundle skipped because of a configuration problem: Can not find rpmbuild 4 or newer..
> Advice to fix: Install packages needed to build RPM, version 4 or newer.
> I’m on a Debian machine, trying to create an OS-specific (i.e.,
> Debian) image, so this was a confusing message. (Yes, I know it’s
> possible to create rpms under Debian if you have the right tools
> installed, but that’s not what I was trying to do here.)
> - What’s more, even though the tool exited on error it still produced
> a Debian package in the output directory, but I found it only by
> - Looking at the content of the generated Debian package, the control
> file has many fields that don’t have corresponding jpackage options.
> That could be a problem for some developers.
> - The data in the Debian package would place the application into a
> directory named `/usr/bin/hello`, which is completely wrong. Please
> see the Filesystem Hierarchy Standard  and the Debian Policy
> Manual  for details.
> - I tried to create a package that would install into the `/opt`
> directory by appending `--install-dir /opt` to the above command
> line. The data in the resulting package would indeed install into
> `/opt`, but the structure within that directory would be incorrect.
> There should be an `/opt/hello/bin` directory containing the `hello`
> launcher, and the remainder of the content should be organized per
> the usual conventions .
> To get this into better shape I suggest that you seek advice and, when
> appropriate, reviews from developers who have deep experience with the
> rpm and deb package formats (there are several such people here in the
> OpenJDK Community). It’d also be good to get feedback from macOS and
> Windows packaging experts, but I don’t personally know of any.
> - Mark
>  https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JDK)%20AND%20component%20in%20(tools)%20AND%20Subcomponent%20in%20(jpackage)%20and%20statuscategory%20not%20in%20(Done)
>  http://www.pathname.com/fhs/pub/fhs-2.3.html#USRBINMOSTUSERCOMMANDS
>  https://www.debian.org/doc/debian-policy/index.html
>  http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
More information about the core-libs-dev