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

[Mattia Rizzolo]

On Wed, Nov 08, 2017 at 04:58:49PM -0800, Diane Trout wrote:
> - TODO Recommit symbols file
> 
> > 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.

The KDE tool is not kde-specific at all.
Nonetheless, I don't really advocate for it: it might make easier to
update the symbols file and stuff, but IMHO it also makes too easy to
just "automatically update symbols file" and overlook what the actual
changes are.  In particular, C++ symbols tends to be way way more
tedious than plain C ones.
If your upstream is sane and does a decent job at dealing with symbols,
manually taking care of a symbol file is very easy.  Please just commit
your first shot at it, and I'll happily help out in shaping it (and
making it right for all the other architectures if there are
arch-specific symbols).

As a gotcha, remember that this bug was born out of the fact that there
was a package requiring a >= 1.5 dependency.  I recommend you compile
the symbol file with something << 1.5 (i.e. 1.4 or just re-add the file
that was removed) and then update it appropriately so there will be not
so tight versions.

> > > 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.

Can I recommend dealing with the public/non-public API *after* adding
the symbols file and doing other general stuff?

In general, I recommend against doing dozens of (possibly hard, like in
this case) changes in a single huge upload, let's split them out :)

Upstream kindly opened #881170 to track other issues as well, perahps
clone that bug to track all those issues separately (as they all require
changes to other packages, so need to be coordinated separately, and
need not to be done at the same time either).


If you find issues getting stuff sponsored, please do point me to it
privately (I know you are on IRC, that tends to often work best for me).
-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20171109/1875415b/attachment.sig>