[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Uploaded new version 1.6 of htslib, samtools & bcftools to experimental - any known issues with reverse dependencies



On Tue, Dec 12, 2017 at 11:17:22PM +0000, John Marshall wrote:
> But in short, upstream's guiding principle is this: API and ABI are
> tightly related. If functions that are not declared within htslib/*.h
> (therefore are not part of HTSlib's documented public API) are
> changed, we do not consider that to be an ABI change. Third-party
> code should not be calling such functions, end of story.
> 
> To use debug_vbuf() or hopen_json_redirect() or these other functions,
> authors of client code would have to search for them in the internal
> part of HTSlib's source code and copy suitable declarations into their
> own code in order to call them or otherwise use them. We do not
> consider that to be a supported use of the HTSlib library, and I
> think you would struggle to find any other library that supported
> such use. If such things were supported, how could library authors
> make changes to the behaviour of any (non-static) internal functions
> ever [1]?

Changing the behaviour is totally orthogonal to breaking ABI, in my
opinion.  Breaking the ABI means an application dynamically linked to it
won't even start.

> This argument applies to all of the functions mentioned in your email.
> 
> What is the argument in favour of considering clearly unsupported
> undocumented internal functions to be part of a library's interface
> just because symbols are visible — in the binary but not the headers?

I've been convinced off list to not being so uptight in technicalities.
My argument would be only about definitions and being "academically
right", which is clearly way too overzealous sometimes...
Let's just say those functions were private and are not supposed to be
used by anything, so it's "fine enough" to just drop them from the
symbols list.

> [1] Yes, we're aware of non-portable visibility declarations, and
> have historically had limited interest in taking up that maintenance
> burden in HTSlib.

I see. pity :)

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

Attachment: signature.asc
Description: PGP signature


Reply to: