[Debian-med-packaging] Bug#796917: snappy1.0.3-java: dependency on libsnappy1

[Andreas Tille]

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 (<i>os.name</i> and
 * <i>os.arch</i>). 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:
 * <ol>
 * <li>(System property: <i>org.xerial.snappy.lib.path</i>)/(System property:
 * <i>org.xerial.lib.name</i>)
 * <li>One of the libraries embedded in snappy-java-(version).jar extracted into
 * (System property: <i>java.io.tempdir</i> or if
 * <i>org.xerial.snappy.tempdir</i> is set, use this folder.)
 * <li>Folders in LD_PATH environment variable (This is the default path that
 * JVM searches for native libraries)
 * </ol>
 * 
 * <p>
 * If you do not want to use folder <i>java.io.tempdir</i>, set the System
 * property <i>org.xerial.snappy.tempdir</i>. For example, to use
 * <i>/tmp/leo</i> 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