[Debian-med-packaging] Convenience code copy of samtools and tabix in r-bioc-rsamtools.

Charles Plessy plessy at debian.org
Mon Nov 4 13:04:05 UTC 2013


Le Mon, Nov 04, 2013 at 09:50:45AM +0100, Andreas Tille a écrit :
> 
> Should we apply
> 
> diff --git a/debian/watch b/debian/watch
> index 3d2e134..c920547 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,2 +1,2 @@
>  version=3
> -https://github.com/samtools/samtools/tags .*/v?(\d[\d\.]+)\.tar\.gz
> +https://github.com/samtools/samtools/tags .*/v?(\d[-\d\.rc]+)\.tar\.gz
 
> What would you think should be the starting point:  Packaging htslib and
> bcftools now, wait until it might pass new queue and update samtools
> once this has happened?
 
> Back to the Rsamtools package.  I did some experiments to try convincing
> the R Build-System to use -lbam instead of its own libbam.a but failed.
> For me this automatism that is called is bit mysterious and I have not
> found any hook to drop in some alternative library.  Since it obviously
> takes a lot of time to work down the whole BioConductor dependency tree
> to get r-bioc-cummerbund updated to its latest version (which was simply
> the reason for all my BioC work and which turned out way harder than
> expected) I'm tempted to push the package to new with some remark that
> we are aware about the code copy and will try to find a reasonable
> solution in an upgrade / later version of this package.  Do you have any
> better idea?

Hi Andreas,

I agree with your view.

Here are extra comments:

 - for samtools, we need to ensure that this upcoming version 0.2, which feels
   like being actually like a 2.0, is not breaking backwards compatibility.  If
   it would be the case, then we should make a samtools0.2 package.

 - In the meantime, I recommend to avoid the rc releases of samtools in Unstable,
   so that you can concentrate of getting Rsamtools and r-bioc-cummerbund up to
   date in the short term.  I think that we are in a situation where we are able to do
   the extra work in case a severe flaw is found in the samtools source, which would
   need to correct all related packages.

 - In the longer term, we need to package the bcftools and the htslib.

 - If these packages do not provide dynamic libraries, it may be a good time
   for us (me ?) to ask for it.  In parallel or after, somebody (you ?) needs to
   ask the Rsamtools upstream to migrate to samtools 0.2, and take the opportunity
   to use the libraries directly.

I will help with the packaging work related to the 0.2 version of samtools.

Cheers,

-- 
Charles



More information about the Debian-med-packaging mailing list