symbol versions in public libs

[Andrew Bartlett]

On Thu, 2023-08-03 at 19:09 +0300, Michael Tokarev via samba-technical
wrote:
> Hi!
> 
> This is a JFYI email, to show how we have to fix samba build
> procedure to produce manageable packages for debian.
> 
> During 4.17 stable series, there were a few new symbols appeared
> in libldb, versioned LDB_2.7.1 and LDB_2.7.2.  For example,
> 
>   ldb_msg_remove_inaccessible at LDB_2.7.2
> 
> However, new major version (samba 4.19, ldb 2.8.0) have these
> symbols at version 2.8.0, not 2.7.2.  The result is that all
> binaries linked with ldb-2.7.2 using these symbols does not
> work with ldb-2.8.0, even if all actual code is exactly the
> same.
> 
> This is because symbols "backported" from the next major release
> to previous stable series are marked as belonging to this next
> major release, not to the previous stable where they backported
> to, even if no next major release has been released yet.
> 
> For a downstream distribution this is unacceptable. There are
> two ways to deal with this situation:
> 
>   1) migrate all reverse-dependencies (users of this library)
>      to the new ABI, bumping the soname.  This will divirge from
>      upstream naming, since upstream uses libldb2, while we'll
>      have to use libldb3, libldb4 etc - bumping soname each time
>      such symbol version bump happens.
> 
>   2) provide symbols at older versions for new upstream major
>      release and keep soname.
> 
> Either way means we have to patch upstream build system.
> 
> I've choosen the 2) way, by providing missing ldb-2.7.1.syms
> and ldb-2.7.2.syms files for ldb-2.8.0.  I'll have to keep the
> old/missing .syms forever, they'll accumulate in debian/patches/
> with time.  This is not bad actually, since it's static contents.
> 
> I'm not sure what value such versioning gives if it forces
> downstream to jump though hoops like this. But here we are.
> 
> Thinking about it more, I'd just remove this @LDB_foo suffixing
> entirely, - it will be much easier to deal with.  Unfortunately
> this means we'll have to bump the soname again, or try to provide
> both versioned and unversioned symbols somehow, - which means
> patching waf which is not static target - which I'd try to avoid
> since it means constant maintenance with each waf update.

This is very interesting, and to me just adds to the argument to un-
version and re-bundle LDB.  Our only downstream user (sssd) uses the
modules API which is not ABI guaranteed anyway. 

If we don't do that, I don't see any good solutions.  Security releases
are enough of a pain without coordinating ABI file updates between the
releases, and in any case, if we have these updates:

ldb 2.0.1 -> ldb-2.0.2
ldb 2.1.2 -> ldb-2.1.3
ldb 2.2.3 -> ldb-2.2.4

The symbol won't be present in ldb 2.1.1 or 2.1.2 for example, but if
we put in the ABI file as appearing in 2.0.2 it makes it seem like it
was.  This comes from trying to use ABI versions as package versions,
and having package-version in lock step with Samba major versions.

This is difficult.  Hmm.

Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead                https://catalyst.net.nz/services/samba
Catalyst.Net Ltd

Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company

Samba Development and Support: https://catalyst.net.nz/services/samba

Catalyst IT - Expert Open Source Solutions