Bug#764630: missing JNI path in jarwrapper

[Mathieu Malaterre]

On Fri, Nov 21, 2014 at 12:23 PM, Emmanuel Bourg <ebourg at apache.org> wrote:
> On Thu, 30 Oct 2014 10:36:02 +0100 Mathieu Malaterre <malat at debian.org>
> wrote:
>
>> Currently jarwrapper is used as backend for binfmts (not sure why this
>> is not jexec). Anyway the script is incomplete, now that we have
>> multi-arch JNI location:
>
> This is tricky, because if we add the multi arch path based on the
> output of dpkg-architecture, we'll still get an error with a 32 bits JRE
> on a 64 bits system. The java.library.path parameter would point to
> /usr/lib/x86_64-linux-gnu when it should actually include
> /usr/lib/i386-linux-gnu.
>
> A solution would be to remove the java.library.path parameter from
> jarwrapper. The openjdk-*-jre packages already include the right
> multiarch path so it's not necessary to add this parameter in this case
> (I verified dicomscope starts without it). But if an Oracle VM is used
> instead it would still break.

Maybe this is time to change the Java policy §2.4 Java libraries

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

This means that dicomscope package would install only the `jar` file,
and the x86 or x86_64 native lib (*.so) can be installed whether the
user want the 32bits or the 64bits version.

Comments ?