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