Bug#764630: RFS: javatools 0.48 [RC]

[Markus Koschany]

On 12.12.2014 07:05, tony mancill wrote:
[...]
> Any concerns from the team?  This is kind of a brute force approach, but
> seems reasonable.  My question is:
> 
> Do we feel confident that this the lists below are representative for
> for jessie?
> 
>> MULTIARCH_LIBRARY_PATH_32BIT="/usr/lib/jni:/usr/lib/arm-linux-gnueabi/jni:/usr/lib/arm-linux-gnueabihf/jni:/usr/lib/i386-gnu/jni:/usr/lib/i386-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/i386-kfreebsd-gnu/jni:/usr/lib/mips-linux-gnu/jni:/usr/lib/mipsel-linux-gnu/jni:/usr/lib/powerpc-linux-gnu/jni:/usr/lib/powerpc-linux-gnuspe/jni:/usr/lib/sparc-linux-gnu/jni:/usr/lib/x86_64-linux-gnux32/jni:/usr/lib/hppa-linux-gnu/jni:/usr/lib/sh4-linux-gnu/jni:/usr/lib/m68k-linux-gnu/jni"
>>
>> MULTIARCH_LIBRARY_PATH_64BIT="/usr/lib/jni:/usr/lib/alpha-linux-gnu/jni:/usr/lib/x86_64-linux-gnu/jni:/usr/lib/aarch64-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/powerpc64-linux-gnu/jni:/usr/lib/powerpc64le-linux-gnu/jni:/usr/lib/s390x-linux-gnu/jni:/usr/lib/sparc64-linux-gnu/jni"
> 

Hi,

since nobody seems to have any comments, let me chime in here. The list
above is complete and contains all possible 32bit and 64bit multiarch
paths. There was one mistake with kfreebsd-64 but this one has been
already fixed two days ago. As you rightfully wrote above, this is some
kind of brute force approach but I'm confident that it covers all
possible scenarios. Now the code checks what kind of JVM is used and
adds the respective MULTIARCH_LIBRARY_PATH to -Djava.library.path.
Actually I would prefer that all JREs would handle that by themselves
but it seems so far only OpenJDK is capable of doing it.

> Or should jarwrapper honor MULTIARCH_LIBRARY_PATH (or
> JARWRAPPER_MULTIARCH_LIBRARY_PATH, or similar) in the environment?  Just
> in case we missed something or something else comes along.  If present,
> perhaps this could be added after /usr/lib/jni, and before the other
> components of the path.


The downside of this approach is that we need to add new multiarch paths
to jarwrapper whenever a new architecture gets introduced to Debian.
However I think this is manageable. The purpose of jarwrapper is to set
up binfmt-misc to run executable jar files. I feel that no further user
or maintainer interaction should be necessary in addition to that. It
should just work (TM). So in my opinion it would be better if it did not
honor any additional environment variables and simply did its job.

> Markus, thank you for working on this.

You're welcome. Perhaps this is the right opportunity to raise some
questions about javatools and the current Java policy in general. The
trigger for this bug report was the dicomscope package which includes
arch:all and arch:any components namely jni libraries. According to the
current Java policy this is not a violation.

The bug reporter suggested [1] to change §2.4 of the Java policy

From:

[...]
These dynamic libraries *should* be shipped in a separate
architecture-specific package named libXXX[version]-jni.
[...]

to:

[...]
These dynamic libraries *must* be shipped in a separate
architecture-specific package named libXXX[version]-jni.
[...]

What is the team's stance on this issue?

Actually what was the reasoning behind the choice to use a custom shell
script like jarwrapper instead of jexec to register executable jars with
binfmt-misc? This question also came up in the bug report.

Cheers,

Markus


[1] https://bugs.debian.org/764630#65



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20141214/37d0c00b/attachment.sig>