Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
Hi everyone, I talked some with upstream about the symbols issues with htslib2 https://github.com/samtools/htslib/issues/616 They think that cram/*.h are private headers, but because we have a policy of avoiding convenience copies we made those functions public[1] because a few applications embed htslib and directly use the private headers. I do think we should bring back the symbols file, but 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. 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. Diane [1] https://anonscm.debian.org/cgit/debian-med/htslib.git/tree/debian/p atches/htslib-add-cram_to_bam.patch
Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
على الجمعـة 3 تشرين الثاني 2017 17:52، كتب Diane Trout: > There was also symbols removed between 1.4.1 to 1.5 but upstream didn't > change their SOVERSION. > > As an aside while I was looking at the missing symbols I found mfprintf > was still listed in htslib 1.5's cram/mFILE.h, but the implementation > had been removed from cram/mFILE.c > > Should we be patching the SOVERSION? > File a bug upstream to have them update SOVERSION? This was upstream's advice [1]: > (When your symbols script comes up with MISSING it would be helpful > if Debian would start by running "git log -S symbolname" which will > usually provide an explanation, rather than assuming that something > terrible has happened. regards Afif 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#56 -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
On Fri, Nov 03, 2017 at 02:52:11PM -0700, Diane Trout wrote: > I restored it with git-revert and rebuilt 1.4.1 and 1.5 and discovered > there were #MISSING# symbols in each rebuild That's at most to be expected, there was a SONAME bump in the meantime. > 1.2 -> 1.4.1 had missing symbols but there was a package name & > soversion bump from libhts1 to libhts2 Exactly. > There was also symbols removed between 1.4.1 to 1.5 but upstream didn't > change their SOVERSION. This is one of the real problem. So if those symbols that were removed were actually supposed to be part of a private API and not exported, and nobody were supposed to try to reach them, then perahps they might be marked as optional. But it needs to be evaluated accurately on a symbol-by-symbols basis. Personally, from the very quick look I had at them the other day, they didn't look like some "private API". > As an aside while I was looking at the missing symbols I found mfprintf > was still listed in htslib 1.5's cram/mFILE.h, but the implementation > had been removed from cram/mFILE.c mh what the.. > Should we be patching the SOVERSION? > File a bug upstream to have them update SOVERSION? Depending on the kind of upstream, I'd either try to reach out to them and see what are their plan for the next release where they could bump the version, or rename the binary package to get things rebuilt appropriately (unless we decide to declare those symbols as optional…). Diane: thank you for dealing with this bug. -- 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 `- signature.asc Description: PGP signature
Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
> I believe that adding the symbols file back in is the correct solution. > It should allow dpkg-shlibdeps to generate the correct libhst2 > dependencies version. > > Diane > > Graham pointed out there was a symbols file from 1.2 that was removed. I restored it with git-revert and rebuilt 1.4.1 and 1.5 and discovered there were #MISSING# symbols in each rebuild 1.2 -> 1.4.1 had missing symbols but there was a package name & soversion bump from libhts1 to libhts2 There was also symbols removed between 1.4.1 to 1.5 but upstream didn't change their SOVERSION. As an aside while I was looking at the missing symbols I found mfprintf was still listed in htslib 1.5's cram/mFILE.h, but the implementation had been removed from cram/mFILE.c Should we be patching the SOVERSION? File a bug upstream to have them update SOVERSION? Diane
Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
> Would adding a symbols file back to the htslib packaging be an
> alternative solution to manually overriding ${shlibs:Depends} in
> samtools, bcftools, and python-pysam? The build-depends in these
> packages are always versioned appropriately.
>
I believe that adding the symbols file back in is the correct solution.
It should allow dpkg-shlibdeps to generate the correct libhst2
dependencies version.
Diane
Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes
على الجمعـة 27 تشرين الأول 2017 09:55، كتب Mattia Rizzolo:
> On Fri, Oct 27, 2017 at 12:52:31AM -0400, Afif Elghraoui wrote:
[...]
>
> What would have been good to prevent the current breakage that has been
> brought to my attention (samtools), what happened is that the newest
> version of samtools picked up a symbol that was not in the original
> libhts2. Remember that adding symbols is not an ABI break. Though,
> that requires using a versioned dependency, which in a perfect world
> would be provided (forced?) by a proper htslib packaging.
>
>
Would adding a symbols file back to the htslib packaging be an
alternative solution to manually overriding ${shlibs:Depends} in
samtools, bcftools, and python-pysam? The build-depends in these
packages are always versioned appropriately.
regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
