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