Regression after jpackage+1-49 update

[Alexey Semenyuk]

On 10/8/2019 1:53 PM, Sverre Moe wrote:
> tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk 
> <alexey.semenyuk at oracle.com <mailto:alexey.semenyuk at oracle.com>>:
>
>
>
>     On 10/8/2019 12:43 PM, Sverre Moe wrote:
>     > Some comments about the jpackage+1-49 update.
>     >
>     > 1) It has become a lot more verbose since jpackage+1-35. Makes
>     using the
>     > verbose argument difficult to actually see relevant output, like
>     the actual
>     > rpmbuild/dpkg command output.
>
>     > It is running a lot of ldd commands, is that necessary? They are
>     extremely
>     > verbose.
>     ldd is used in building a list of prerequisite packages. ldd is
>     applied
>     to every shared library and binary in app's image, that is why it is
>     invoked so many times.
>
> Is this new in jpackage+1-49? It was not part of the verbose output 
> using jpackage+1-35.
Correct. jpackage tries to build list of packages needed by application 
(mostly by Java runtime) since 1-49.

>     > Perhaps jpackage needs different verbosity levels if anyone is
>     actually
>     > interested in all these ldd outputs.
>     >
>     > The dpkg command fails a lot with IOException.
>     > dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6
>     > java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6]
>     exited with
>     > 1 code
>     The command tries to locate a package providing
>     /usr/lib64/libX11.so.6
>     needed by one of binaries in app image and fails. Does
>     /usr/lib64/libX11.so.6 exist?
>
> All the files it tries to locate does exist, but it still fails with 
> an Exception.
>
> Running [dpkg, -S, /usr/lib64/libXrender.so.1]
> dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1
> java.io.IOException: Command [dpkg, -S, /usr/lib64/libXrender.so.1] 
> exited with 1 code
>        at 
> jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68)
>        at 
> jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$initLibProvidersLookup$13(LinuxDebBundler.java:239)
>        at 
> jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.lambda$execute$1(LibProvidersLookup.java:64)
>        at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>        at 
> java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1694)
>        at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>        at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>        at 
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
>        at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>        at 
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
>        at 
> jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.execute(LibProvidersLookup.java:75)
>        at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.getListOfNeededPackages(LinuxPackageBundler.java:210)
>        at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.createDefaultReplacementData(LinuxPackageBundler.java:236)
>        at 
> jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:175)
>        at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627)
>        at 
> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513)
>        at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98)
>        at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51)
> Could the error message from dpkg be because I am not running on a 
> Debian type distribution.
Yes. This is the reason for all failures with `dpkg -S` command.
> > dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1
> Building an DEB package has not been a problem before on a RedHat type 
> distribution.
Failures of `dpkg -S` command are harmless, application package will 
just have empty list of prerequisite packages.
We should probably not run `ldd` and subsequent `dpkg -S` commands in 
the environment where `dpkg -S` fails. Filed [1] to track this.

>
>     > 2) Previous resources for RPM are no longer used:
>     > The resources for application.desktop and application.png is no
>     longer used
>     > with building RPM.
>     > Have these been removed? Nothing in the changes listed since
>     previous build
>     > has any mention that this has been removed.
>     >
>     > With jpackage+1-35
>     > Using default package resource java32,png [menu icon] (add
>     application.png
>     > to the resource-dir to customize)
>     > Using default package resource template,desktop [Menu shortcut
>     descriptor]
>     > (add application.desktop to the resource-dir to customize)
>     > Using default package resource template.spec [RPM spec file] (add
>     > application.spec to the resource-dir to customize)
>     >
>     > With jpackage+1-49
>     > Using default package resource template.spec [RPM spec file] (add
>     > application.spec to the resource-dir to customize)
>     We don't add desktop integration in the package by default unless
>     there
>     is one of `--icon` `--file-associations` options on jpackage
>     command line.
>     To force adding desktop integration in the package you need to
>     specify
>     `--linux-shortcut` option. See [1]
>
>     - Alexey
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8229779
>
> Thanks, adding the --linux-shortcut solves that problem.
> However it seems to be a regression there in choosing the desktop 
> resource file.
>
> Using default package resource template.desktop [Menu shortcut 
> descriptor] (add application-application.desktop to the resource-dir 
> to customize)
>
> It should be just "application.desktop", not 
> "application-application.desktop".
XDG recommends .desktop files should have vendor prefix.
jpackage uses package name as a prefix for .desktop files it registers 
in the system with `xdg-desktop-menu` command.
However the prefix should not be used when looking up for a file in 
resource directory.
So you are right, this is a regression. I filed [2] to track this.

- Alexey

[1] https://bugs.openjdk.java.net/browse/JDK-8232024
[2] https://bugs.openjdk.java.net/browse/JDK-8232029

>
> /Sverre
>