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-packag...@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

Reply via email to