Regression after jpackage+1-49 update

[Sverre Moe]

tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk <
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.


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


> 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".

/Sverre