Re: status on picard-tools and issue with libsnappy-java
Le 8/13/12 11:08 AM, Andreas Tille a écrit :
> On Mon, Aug 13, 2012 at 09:27:50AM +0200, olivier.sallou@codeless.fr wrote:
>> I copy below the answer from upstream team.
>> They will not go to latest snappy version. Seems it was quite difficult
>> to integrate it and faced issues.
>>
>> The problem is snappy-java 1.0.4 breaks its API and is not compatible
>> with version 1.0.3 used by picard-tools.
> This is what we also learned (the hard way).
>
>> At runtime, picard-tools tries to detect snappy. If not present, it will
>> be ok. However we still face the problem for Debian for compilation....
>>
>> -------- Message original --------
>> Sujet: Re: [Samtools-help] support of snappy-1.0.4
>> Date : Thu, 09 Aug 2012 10:27:11 -0400
>> De : Alec Wysoker <alecw@broadinstitute.org>
>> Pour : olivier.sallou <olivier.sallou@laposte.net>
>> Copie à : samtools-help@lists.sourceforge.net
>>
>> ...
>>
>> Could you try one of the following alternatives to using latest snappy-java:
>>
>> * Use the same version Picard uses, i.e. 1.0.3-rc3
> It somehow came to my mind to package this older version. Finally we
> started packaging libsnappy-java for the only purpose to support picard
> ... and currently this purpose is not fullfilled.
Too bad....
We could indeed package a libsnappy1.0.3-java (with a conflict on
libsnappy-java, and a recommends on picard-tools) and make picard-tools
depend on this version.
I am on holiday for the moment and won't have much time to manage this.
However, if adding such library (1.0.3) can fix the issue, I could do
this in a few weeks.
>
>> * Omit snappy-java classes completely.
>> net.sf.samtools.util.SnappyLoader is written so that if
>> org.xerial.snappy.SnappyInputStream and
>> org.xerial.snappy.SnappyOutputStream are not found on the classpath,
>> then the code should work without using Snappy.
> Hmmm, I do not know the advantage we would liked to reach and whether
> this is acceptable. However, it seems to make sense to do not only a
> check whether the class is available but also to verify the version if
> there are incompatible versions known. I have no idea whether this is
> possible - but if yes this would be a reasonable hint to upstream.
Incompatible versions should also be detected as expected class will not
be found.
But this does not fix our compilation issue as snappy is still required
for build (with correct version)
> Kind regards
>
> Andreas.
>
>
> --
> gpg key id: 4096R/326D8438 (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Reply to: