On Fri, Nov 21, 2014 at 12:23 PM, Emmanuel Bourg <ebo...@apache.org> wrote: > On Thu, 30 Oct 2014 10:36:02 +0100 Mathieu Malaterre <ma...@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 ? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
