[Debian-med-packaging] Bug#879886: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 2:32:56 AM EST, Diane Trout <diane at ghic.org> wrote:
>On Thu, 2017-11-09 at 02:03 -0500, Afif Elghraoui wrote:
>> > - TODO Split private cram headers off into a new libhts-private-dev
>> > package
>> 
>> I'd rather be in favor of restoring the bundled htslib to seqlib as
>> the short term solution. Putting a private package in the archive may
>> exacerbate the problem and is odd nevertheless.
>
>The no convenience copies of libraries is a pretty strong rule of
>Debian, and there are good maintenance reasons for it.

Yes, I understand that, but we don't have good options right now. I don't see the maintenance advantages for seqlib as worth requiring a transition for every htslib update to make sure it doesn't break--in addition to putting a package in the archive and telling users/developers not to install it.

> Although I'm not
>opposed to it I'd like several people to agree that its the best option
>first.
>
>On the plus side overriding it would allow us to drop the patch that is
>making the cram symbols public, on the downside we'd have to remember
>that bugs involving htslib also impact libseqlib.

If this whole situation is primarily seqlib's problem, I think it's only fair for it to bear the kludges required for its approach. Otherwise, we have the kludge in htslib and the need for a htslib transition with every update, right?

In fact, lofreq never entered Debian because it needs to use samtools as a library and we were not going to bundle it [1]. I felt that would be an RC bug.

>
>I think we'd need to use the Built-Using tag? I haven't used that
>before.
>
>On the other hand upstream did suggest that the private-dev library was
>a viable temporary solution. (Though doing that would push htslib into
>NEW).

Well, I think they were saying that if we were going to go so far as to misrepresent htslib, we should at the very least make a division and distribute htslib proper as such. I read that as saying anything would be better than the current situation--not necessarily that they're equally better.

>
>> 
>> And there is another action item--
>> TODO update the htslib package to the latest release.
>
>Very true.... I did try building 1.6 and there was a problem with
>running tests that I haven't investigated yet.
>

Regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808895