[Debian-med-packaging] Fwd: [htslib] Missing symbols in htslib 1.3 (#311)

[Sascha Steinbiss]

FYI. I received a reply to my upstream inquiry. In this light it is probably enough to update the symbols file — any comments?

Best
Sascha

> Begin forwarded message:
> 
> From: John Marshall <notifications at github.com>
> Subject: Re: [htslib] Missing symbols in htslib 1.3 (#311)
> Date: 30 December 2015 at 01:10:08 CET
> To: samtools/htslib <htslib at noreply.github.com>
> Cc: Sascha Steinbiss <satta at tetrinetsucht.de>
> Reply-To: samtools/htslib <reply+00006c5472af1d04666d0d204127b7fe850b0c6792129fa292cf00000001129ae2e092a169ce0760b63d at reply.github.com>
> 
> bcf_empty1() was previously not declared or even mentioned in a header file, so was not useable in previous htslib releases. Effectively bcf_empty() and bcf_empty1() have been freshly added to the public htslib API in 1.3. See d4482eb <https://github.com/samtools/htslib/commit/d4482eb578aada0080eb30239ff57e9f6a6de93b> for details.
> 
> int32_get() and int32_put() were internal functions private to the library. They were not declared in any header file and were not part of the API. Similarly hts_idx_load_local() is not declared in any header and is not part of the API, so making it static was intended and does not affect either public API or ABI.
> 
> MD5_Update()/MD5_Final()/MD5_Init() were badly-named internal functions private to the library. Defining these functions with their OpenSSL names (and via implementations unlikely to be using the context data compatibly) was a bug, and removing them fixed the bug. See 3accd19 <https://github.com/samtools/htslib/commit/3accd1934472e2bdd501404f4c1a2e570f868cd1> and PR #180 <https://github.com/samtools/htslib/pull/180> for details.
> 
> There were no declarations for these MD5_* functions in HTSlib's header files and they were not part of the HTSlib API. To be affected by this change, client code would have to be including declarations from OpenSSL headers and linking against libhts.so and libssl.so, in which case functions previously satisfied by libhts will be satisfied by libssl and all will be well; or it would have to be including OpenSSL headers but linking only against libhts.so, in which case it will fail and deservedly so.
> 
> None of these symbols that have been removed from the library are part of the public HTSlib API, and none of them even appear in previous releases' public header files. Thus to use these symbols, client code would have had to go out of its way to create its own declarations for these functions — which is a kind of client code that essentially no library supports.
> 
> We considered each of these symbol removals as we made them, and judged in each case that as they are not part of the documented/supported HTSlib API their removal does not cause backwards-compatibility problems and does not constitute a change in the library's public ABI. Therefore we considered that no soversion bump was necessary.
> 
> Now that you have the rationale for each case, we hope that Debian will agree that neither the proposed fixup_symbols.patch.txt wrappers nor a soversion bump are needed.
> 
> —
> Reply to this email directly or view it on GitHub <https://github.com/samtools/htslib/issues/311#issuecomment-167903183>.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20151230/170fc62b/attachment-0001.html>