[ldns-users] ldns SONAME, what shall I do?

[Willem Toorop]

Hi Ondřej and other list members,

I am about to release the new ldns and I am still not completely sure
what to do with the SONAME.  Advice and input from you on the ldns-users
and the the maintainers would be much appreciated.

ldns before version 1.6.14 had a bug (#459) which caused all symbols
(including symbols for compatibility support functions) to be visible.
The disappearance of one such symbol (strlcpy) caused the OpenDNSSEC
build on Debian to break.

As a consequence of bug fix #459 the Application Binary Interface (ABI)
of ldns had changed.  Normally, when the ABI is broken on purpose, the
SONAME version is bumped so that builds against the earlier ABI version
don't try to link against the current one.

Ondřej worked around the issue by a hard build dependency on ldns >=
1.6.14 for OpenDNSSEC.  No other issues involving disappeared symbols
seem to have popped up; at least, not that I'm aware of.

Now I can release the new ldns with a updated SONAME.  In our other dns
library, libunbound, this reversioning of the SONAME (not the bug) has
been done several times before.  It even has a specific versioning
scheme for this.

My hesitation for doing so is that this will hinder people with a
source/build based package management systems the most.  People that use
ports on FreeBSD and OpenBSD, or pkgsrc on NetBSD.  They have to rebuild
everything dependent on ldns, and have to be warned to do so manually
(via UPDATING file in FreeBSD).

This is even more painful because those systems do have strlcpy in their
system libraries.  For them ldns versions before and after 1.6.14 are
completely binary compatible! For them there is absolutely no reason to
update the SONAME!

Now, if it is all the same to everybody, I'm fine with releasing
ldns-1.6.17 that will install libldns.so.1.6.17.  But strictly 1.6.14
should have been released as libldns.so.2.  How realistic do you think
it is that ldns will be updated to 1.6.17 from a version earlier than
1.6.14?  In other words, what do you think that should happen?

Thanks for your advice and a Happy Christmas :)

-- Willem

op 17-07-13 08:35, Ondřej Surý schreef:
> Hi Willem,
> 
> On Tue, Jul 16, 2013 at 2:42 PM, Willem Toorop <willem at nlnetlabs.nl
> <mailto:willem at nlnetlabs.nl>> wrote:
> 
>     Hi Ondřej, Bas,
> 
>     This is unfortunate.
>     Those symbols disappeared in 1.6.14 when addressing bugfix #459.
>     (https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=459)
> 
>     B.t.w. I cannot reproduce myself. When I compile OpenDNSSEC 1.3.14 or
>     1.3.4 with ldns 1.6.11, configure detects the absence of strlcpy and
>     compiles and links the replacement function via libcompat.a (even though
>     strlcpy is also available in libldns.so.1 !). This is with gcc 4.6.3. It
>     would be interesting to see the output of the build process, to see
>     where it differs.
> 
> 
> All build logs are here (also my analysis could be just wrong):
> 
> https://launchpad.net/~pkg-opendnssec/+archive/ppa/+builds?build_state=built
>  
> 
>     [...]
>     Most convenient for me would be to postpone the soname bumping release
>     (1.7.0) until the end of August (to be on the safe side). Would that be
>     acceptable for you? It means that the libldns1 package may not be
>     updated to 1.6.14 or beyond until that time. Alternatively you could
>     package a patched libldns1 1.6.16 that does export the strlcpy symbol
>     (nasty). I have attached a patch that does just that.
> 
> 
> I will just add hard build dependency on ldns >= 1.6.14 and that will
> fix the problem. And let's hope it will not pop-out somewhere else.
> 
> Ondrej
> -- 
> Ondřej Surý <ondrej at sury.org <mailto:ondrej at sury.org>>