Re: status on picard-tools and issue with libsnappy-java
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.
> * 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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: