[Debian-med-packaging] Bug#822701: Bug#822701: Bug#822701: samtools: FTBFS: UNEXPECTED PASS: Task worked when we expected failure;

Afif Elghraoui afif at debian.org
Tue May 3 04:54:49 UTC 2016


Hi, Charles,

I'm sorry for my late reply

على الثلاثاء 26 نيسـان 2016 ‫21:38، كتب Charles Plessy:
> Le Wed, Apr 27, 2016 at 10:12:31AM +0900, Charles Plessy a écrit :
>>
>> Perhaps we also need htslib 1.3.1 to "Break" samtools < 1.3.1... I cloned
>> this bug to address that issue.
> 
> Hi all,
> 
> I added: "Breaks: samtools (<< 1.3.1)".  I think that it would be better to
> update the package before backporting it to Jessie.  Are there other opinions,
> or other changes to make to the package ?
> 

This seems to happen with every htslib upgrade in the past few releases.
bcftools builds have also been breaking as a result and I was a little
confused. Aren't backwards-compatibility breaks supposed to be indicated
by soname bumps? Or is this because samtools, bcftools, and htslib are
all maintained by the same group, so they rely on the unstable internal
interfaces?

If that's the case, maybe every htslib release should be marked as
breaking lower versions of samtools and bcftools. And should samtools
and bcftools have run-time dependencies on libhts1 (=${binary:Version})?


So htslib:

Breaks: samtools (<< ${binary,Version}, bcftools (<< ${binary:Version})

samtools/bcftools:

Depends: libhts1 (>= ${binary:Version})

What do you think? For bcftools so far, I have only been constraining
the build-depends on htslib to be the corresponding upstream version at
a minimum.

regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name



More information about the Debian-med-packaging mailing list