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

[Sascha Steinbiss]

Hi all,

I'd like to bring this back to your attention since IMHO a timely update
of samtools + htslib is a good idea. Should we in this case just update
the symbols file without a ABI version bump? Any opinions?

Thanks
Sascha

On 30/12/2015 09:33, Sascha Steinbiss wrote:
> 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
>> <mailto: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
>> <mailto:htslib at noreply.github.com>>
>> *Cc: *Sascha Steinbiss <satta at tetrinetsucht.de
>> <mailto:satta at tetrinetsucht.de>>
>> *Reply-To: *samtools/htslib
>> <reply+00006c5472af1d04666d0d204127b7fe850b0c6792129fa292cf00000001129ae2e092a169ce0760b63d at reply.github.com
>> <mailto: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>.
>>
> 
> 
> 
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.