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

[Diane Trout]

One of the htslib developers filed a new bug,

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

asking us to not make their private libraries public. His suggestions
are fairly similar to whats Charles proposed.

What I'm thinking is:

- TODO Recommit symbols file
- TODO Split private cram headers off into a new libhts-private-dev
package
- WAITING Try to talk htslib & SeqLib developers to agree on a public
cram api so we can drop the private-dev package.


> 
> Symbols file are strange to work with because their update usually
> goes
> through a build failure that outputs a patch, which is not very
> intuitive.  And then the patched symbols file has to be edited to
> remove
> the Debian minor version, otherwise it complicates backports etc.
> Perhaps it can be simplified, better explained and streamlined.  In
> any
> case, I think that for the htslib it is worth the effort.

The KDE team had some nice utilities that downloaded the symbols files
for all the architectures and could do batch patches.

Unfortunately I think they're KDE specific.

I'll commit my rebuilt symbols files the next time I'm not spending my
day writing emails to everyone else. I need a chance to look more
carefully if the missing symbols were actually not part of the private
api.


> 
> > I was wondering if we should split the cram headers into a
> > libhts-private-dev so we can at least track what is depending on
> > the
> > non-public api.
> 
> An ideal solution, and I understand that it may not be easy, would be
> to
> make the upstream users of htslib talk with the htslib developers, so
> that they can implement what they want to without needing to access
> private functions.  I think that it would fit the aims of both sides.

I wonder if I can forward one Debian bug to multiple upstreams

But I tried to get SeqLb & htslib to talk to each other.

SeqLib issue: https://github.com/walaj/SeqLib/issues/21
htslib issue: https://github.com/samtools/htslib/issues/619

> 
> > I did realize that my thought about updating the SOVERSION might be
> > wrong because I was just looking in the source tree for the removed
> > functions but I should have been checking the public header files.
> 
> Indeed, packages using private functions need to have a tight
> dependency
> on the htslib (unless we are very confident that there are regression
> tests that cover this area of the code).  Packages that are more
> well-behaved can infer their dependency through the (to be re-added)
> symbols file.



So that implies packaging that uses -private-dev that implies they have
an == dependency on a specific binary version of libhts?

That should probably probably be documented in a README.Debian for the
private-dev package.

Should I push these proposed changes to a clone of the htslib packaging
repository? A branch of the alioth repository, or just push it to the
alioth master?

Diane
>