Regression after jpackage+1-49 update

[Alexey Semenyuk]

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 seems to be running rpmbuild --version twice
> Running [rpmbuild --version]
> RPM version 4.14.1
> Running [rpmbuild --version]
> RPM version 4.14.1
>
> Same goes for dpkg-deb --version. It is run twice.
>
> 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.

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

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

>
> /Sverre
>
>
> man. 7. okt. 2019 kl. 10:15 skrev Alan Bateman <Alan.Bateman at oracle.com>:
>
>> On 07/10/2019 08:00, David Holmes wrote:
>>> On 7/10/2019 4:43 pm, Alan Bateman wrote:
>>>> On 07/10/2019 04:35, David Holmes wrote:
>>>>> Nothing to do with jpackage but a fix to Class.forName to ensure
>>>>> classes are linked as per the specification of forName. You can
>>>>> temporarily workaround with -XX:+ClassForNameDeferLinking, but your
>>>>> code needs to be updated to deal with LinkageErrors from Class.forName.
>>>> In this case, it is core reflection code that it looking at the type
>>>> parameters in the type of a field. I suspect this code needs to
>>>> translate NCDEF to TypeNotPresentException, other linkage errors
>>>> maybe need to be handled here too.
>>> Oops! Yes indeed.
>> I've created JDK-8231924 [1] to track this. We will need to a wider
>> audit of Class.forName usages in the JDK in case there are other issues
>> like this.
>>
>> -Alan
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8231924
>>