symbol versions in public libs

[Michael Tokarev]

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.

JFYI, and thanks,

/mjt