Re: pysam dependencies
Hi Diane,
On Fri, Dec 21, 2012 at 09:12:10PM -0800, Diane Trout wrote:
> Hi,
>
> The other pysam dependency is tabix which I tried to convert it to a shared library.
>
> I put my patch to make tabix use libtool to build static, linux or os x shared libraries at [1]:
Sounds very reasonable.
> However I haven't modified the debian package to actually build a libtabix1 and libtabix-dev package.
While also this step would sound logical to me I'd recommend to send the
libtoolification to tabix upstream and ask for their opinion. It would
be more sustainable if they would adopt this build system. Even if
development seems a bit stalled since 20 months they might at some point
consider new releases and on one hand we need to patch again and on the
other hand I also always keep in mind other (non Debian derived)
distributions that might profit from the change if it goes upstream.
We have a similar example with muscle[3] and libmuscle[4] where we as
Debian developers were not actively involved but failed to convince the
author of muscle to consider adopting the changes of the author of the
libtool patch. This leaves us in certain trouble because it now seems
thet libmuscle is lagging behind and will remain stalled, trying to keep
the patch alive or what else? So trying to convince upstream to take
such stuff over is a good thing to do.
> I discovered that tabix & samtools include slightly different versions of klib[2].
>
> It looks like klib doesn't believe in don't-repeat-yourself as they don't provide a makefile and their readme encourages people to just copy klib files into their own software.
Uhmm, this does look ugly. They do not even seem to maintain a homepage.
I'd definitely consider creating a separate library - my guess is that
this code might be contained in other scientific packages inside Debian.
> Since pysam includes both of samtools and tabix it ends up with duplicates of files: bgzf.[ch], knetfile.[ch], kseq.h, ksort.h, and kstring.[ch]
Thanks for pointing this out.
> A quick diff between the pysam samtools and tabix directories shows bgzf.c has a different api.
>
> I'd like to avoid cleaning up the klib mess, would it be reasonable to have the header files for samtools in something like "/usr/include/bam" and tabix as "/usr/include/tabix"?
I do not think it is needed to make this a short term goal but the
different api point is an issue I would like to solve in the long term.
IMHO the way to solve this is to make the authors of samtools aware that
they are using an outdated copy of klib and should probably mind
upgrading. I also did found a small diff in tabix to klib master but it
seems more recent.
It seems to be even worse because the copyright statment in
samtools/bgzf.c does not mention "Attractive Chaos
<attractor@live.co.uk>" but samtools/knetfile.c does - so it might (or
might not) be that samtools authors cherry picked from different
"releases" of klib. I admit I personally have a personal opinion about
software doing dirty tricks like this - at least I would not base any
publication of mine on it.
So somehow it seems worth to try replacing all klib files in samtools by
the latest master from klib and run dedicated tests on this. Once this
might be successful we should probably forward the possibly needed
patches to samtools authors. Once we can be sure that they are using
the latest klib we have better chances to separate klib in ist own
package.
> Also just to check, can does the dynamic linker treat the same symbol name in two different shared libraries as different?
I have not tried this but we might be able to sort this out on
debian-mentors list.
Thanks for your investigations into this topic
Andreas.
> [1] http://woldlab.caltech.edu/gitweb/?p=tabix.git;a=blob;f=debian/patches/use-libtool;h=58cde517e8e4c6a1c48c5c188399642abe726b7f;hb=build-so
> [2] https://github.com/attractivechaos/klib
[3] http://www.drive5.com/muscle/
[4] http://asap.ahabs.wisc.edu/software/software-development-libraries/libmuscle.html
--
http://fam-tille.de
Reply to: