On Thu, Aug 10, 2017 at 10:18:24AM +0100, Ghislain Vaillant wrote: > On 08/08/17 21:56, Emmanuel Bourg wrote: > > > You'll have to ensure the .so file isn't included in the jar, this may > > require some tweaking of the library loading code. > > I am not sure what you mean here, though that might be because of my > personal ignorance of how JNI works. Could you be a bit more explicit > please? > > I have also looked at similar packages using swig to generate Java bindings. > src:vtk6 [1] does provide separate java and jni packages as you are > proposing, but src:gdcm [2] does not. I have got to say, I am a bit > confused. > > [1] https://packages.debian.org/source/sid/vtk6 > [2] https://packages.debian.org/source/sid/gdcm Hi Ghis, I took a look at gdcm and understand the source of the confusion. Instead of building an arch:all .deb for the Java bits of the JAR and a separate arch:$arch .deb for the native library for JNI, this package is building an arch:$arch -java package. From the output of debc: libgdcm-java_2.8.2-3_amd64.deb ------------------------------ new debian package, version 2.0. size 493632 bytes: control archive=791 bytes. 696 bytes, 18 lines control 287 bytes, 4 lines md5sums Package: libgdcm-java Source: gdcm Version: 2.8.2-3 Architecture: amd64 Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org> Installed-Size: 1208 Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgdcm2.8, libstdc++6 (>= 5.2) Suggests: java-virtual-machine Section: java Priority: optional Homepage: http://gdcm.sourceforge.net/ Description: Grassroots DICOM Java bindings Grassroots DiCoM is a C++ library for DICOM medical files. It is automatically wrapped to python/C#/Java (using swig). It supports RAW,JPEG (lossy/lossless),J2K,JPEG-LS, RLE and deflated. . Java bindings to the GDCM DICOM library. It allows developers to use GDCM from Java environment. drwxr-xr-x root/root 0 2017-08-07 07:28 ./ drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/ drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/lib/ drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/ drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/jni/ -rw-r--r-- root/root 862712 2017-08-07 07:28 ./usr/lib/x86_64-linux-gnu/jni/libgdcmjni.so drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/ drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/doc/ drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/ -rw-r--r-- root/root 7698 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/changelog.Debian.gz -rw-r--r-- root/root 24031 2017-08-07 07:28 ./usr/share/doc/libgdcm-java/copyright drwxr-xr-x root/root 0 2017-08-07 07:28 ./usr/share/java/ -rw-r--r-- root/root 330154 2017-08-07 07:28 ./usr/share/java/gdcm.jar This has the result of building a separate .deb for every architecture [0], which will function as expected up until the time that a user needs multi-arch, at which point the libgdcm-java:amd64 and libgdcm-java:i386 (or whatever arch) packages will fail to co-install because they both contain the same JAR file in /usr/share/java/. That is, this approach "works" in the non-multi-arch case, but should be avoided. Cheers, tony [0] https://packages.debian.org/unstable/libgdcm-java
Attachment:
signature.asc
Description: PGP signature