Bug#764630: missing JNI path in jarwrapper

[Markus Koschany]

Control: tags -1 patch

Mathieu Malaterre <malat at debian.org> wrote:
[...]
> In summary:
> 1. Make jexec the default binfmts (before jarwrapper)
> 2. Update jarwrapper to use the above mentionned `java -d32|64` trick
> to build the library path.


Hi,

I think we have reached a point in the release cycle when it becomes
difficult to predict the outcome of implementing 1. We simply can't
foresee all consequences. We know it works for dicomscope but what about
all the other packages that depend on jarwrapper? Most people depend on
jarwrapper because the Java policy states:

"If the package installs a jar (or a symlink to a jar) as an executable
the package must have an absolute dependency on *jarwrapper or an
equivalent package*"

Now they have certain expectations for jarwrapper and since we haven't
seen any complaints except this bug report so far, we should assume that
jarwrapper works in general.

I suggest the following:

1. Clone this bug report, retitle to "Make jexec the default binfmts
   (before jarwrapper)" and lower the severity to important. This
   change should be discussed on debian-java anyway but it is not RC.

2. Fix this bug by applying the attached patch and removing the
   java.library.path from jarwrapper. As Emmanuel already said before,
   the openjdk packages can find the correct multiarch path and
   jarwrapper should let those packages handle it.

3. Please note that dicomscope could "depend on jarwrapper or an
   equivalent package". You could also write your own wrapper script or
   use java-wrappers instead.

4. I think Mathieu is right and dicomscope should install the native
   libraries into specific *-jni packages. The Java policy should be
   changed to say "must be shipped in a separate package" instead of
   "should". In any case dicomscope:amd64 and dicomscope:i386 are
   currently not co-installable, so the whole discussion about the java
   -d32|64 hack is rather academic at the moment.

On a side note: jarwrapper exports LD_LIBRARY_PATH=/usr/lib/jni. Was
this ever useful because -Djava.library.path is still used?

Regards,

Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fix-764630.patch
Type: text/x-diff
Size: 730 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20141203/9eac4b6e/attachment.patch>
-------------- 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/20141203/9eac4b6e/attachment.sig>