Re: Bug#796917: snappy1.0.3-java: dependency on libsnappy1

2015-09-02 Thread Gianfranco Costamagna
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.



Re: Bug#796917: snappy1.0.3-java: dependency on libsnappy1

2015-09-02 Thread 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 (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