Bug#796917: snappy1.0.3-java: dependency on libsnappy1
Hi, I guess the current dependency was injected due to the fact that the original upstream source contained a copy if libsnappy.so and src/main/java/org/xerial/snappy/LoadSnappy.java says: * This class loads a native library of snappy-java (snappyjava.dll, * libsnappy.so, etc.) according to the user platform (os.name and * os.arch). The natively compiled libraries bundled to snappy-java * contain the codes of the original snappy and JNI programs to access Snappy. * * In default, no configuration is required to use snappy-java, but you can load * your own native library created by 'make native' command. * * LoadSnappy searches for native libraries (snappyjava.dll, libsnappy.so, etc.) * in the following order: * * (System property: org.xerial.snappy.lib.path)/(System property: * org.xerial.lib.name) * One of the libraries embedded in snappy-java-(version).jar extracted into * (System property: java.io.tempdir or if * org.xerial.snappy.tempdir is set, use this folder.) * Folders in LD_PATH environment variable (This is the default path that * JVM searches for native libraries) * * * * If you do not want to use folder java.io.tempdir, set the System * property org.xerial.snappy.tempdir. For example, to use * /tmp/leo as a temporary folder to copy native libraries, use -D option On Tue, Aug 25, 2015 at 09:50:30PM +0200, Julien Cristau wrote: > Source: snappy1.0.3-java > Version: 1.0.3-rc3~dfsg-5 > Severity: serious > > libsnappy1 is being replaced by libsnappy1v5. Your arch:all package has > a hardcoded dependency on the former (how does that even work?). Before I simply add a hardcoded libsnappy1v5 I would like to ask for comments whether there is some better way to solve this. Kind regards Andreas. -- http://fam-tille.de
Bug#796917: snappy1.0.3-java: dependency on libsnappy1
I'm not sure snappy1.0.3-java even works. The native part isn't compiled (the SnappyNative.h and SnappyNative.c files in src/main/java/org/xerial/snappy). So the libsnappy1 dependency is bogus and could be removed. I suggest removing snappy1.0.3-java and use snappy-java instead. This one is known to work. picard-tools is the only reverse dependency of libsnappy1.0.3-java, I'll prepare an update. Emmanuel Bourg
Processed: Please delete snappy1.0.3-java from Debian [Was: Bug#796917: snappy1.0.3-java: dependency on libsnappy1]
Processing commands for cont...@bugs.debian.org: > reassign 796917 ftp.debian.org Bug #796917 [src:snappy1.0.3-java] snappy1.0.3-java: dependency on libsnappy1 Bug reassigned from package 'src:snappy1.0.3-java' to 'ftp.debian.org'. No longer marked as found in versions snappy1.0.3-java/1.0.3-rc3~dfsg-5. Ignoring request to alter fixed versions of bug #796917 to the same values previously set > retitle 796917 ROM: Please remove snappy1.0.3-java from unstable and testing Bug #796917 [ftp.debian.org] snappy1.0.3-java: dependency on libsnappy1 Changed Bug title to 'ROM: Please remove snappy1.0.3-java from unstable and testing' from 'snappy1.0.3-java: dependency on libsnappy1' > thanks Stopping processing here. Please contact me if you need assistance. -- 796917: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796917 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#796917: snappy1.0.3-java: dependency on libsnappy1
Hi Andreas, > libsnappy1 is being replaced by libsnappy1v5. > Your arch:all package has >a hardcoded dependency on the former (how does that even work?).> > >Before I simply add a hardcoded libsnappy1v5 I would like to ask for >comments whether there is some better way to solve this. Well, I'm not a java expert, but in general this approach is wrong. however snappy-java code seems smart enough to understand where to find the library at runtime (this isn't a build-time dependency, but a runtime one) and use it. I'm not sure there is a smarter approach, to let shlibs to its job, because snappy is used as a plugin in this particular case, so hardcoding the libsnappy1v5 might be the best way to do the trick. Did you try if the package works on different architectures? cheers, G.
Bug#796917: snappy1.0.3-java: dependency on libsnappy1
Hi Emmanuel, On Wed, Sep 02, 2015 at 12:54:57PM +0200, Emmanuel Bourg wrote: > I'm not sure snappy1.0.3-java even works. The native part isn't compiled > (the SnappyNative.h and SnappyNative.c files in > src/main/java/org/xerial/snappy). So the libsnappy1 dependency is bogus > and could be removed. > > I suggest removing snappy1.0.3-java and use snappy-java instead. This > one is known to work. picard-tools is the only reverse dependency of > libsnappy1.0.3-java, I'll prepare an update. Cool. Thanks a lot for your upload and the commits to Git! I'll go on ask ftpmaster for removal of snappy1.0.3-java which should be unneeded now. Kind regards Andreas. -- http://fam-tille.de
Bug#796917: snappy1.0.3-java: dependency on libsnappy1
Source: snappy1.0.3-java Version: 1.0.3-rc3~dfsg-5 Severity: serious libsnappy1 is being replaced by libsnappy1v5. Your arch:all package has a hardcoded dependency on the former (how does that even work?). Cheers, Julien signature.asc Description: Digital signature
