JEP 343: Packaging Tool

[Kevin Rushforth]

Hi Mark,

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 
you recommend.

-- Kevin


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 [1], 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
>      itself.
>
>    - 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
>      accident.
>
>    - 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 [2] and the Debian Policy
>      Manual [3] 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 [4].
>
> 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
>
>
> [1] 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)
> [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRBINMOSTUSERCOMMANDS
> [3] https://www.debian.org/doc/debian-policy/index.html
> [4] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES