ldb ABI versions in 4.17: should it include 2.5.1 & 2.5.2 versions too?

[Andrew Bartlett]

On Sat, 2022-09-10 at 14:29 +0200, Andreas Schneider via samba-
technical wrote:
> On Saturday, 10 September 2022 12:20:06 CEST Michael Tokarev via samba-
> technical wrote:
> > 09.09.2022 23:20, Andrew Bartlett via samba-technical wrote:
> > > On Fri, 2022-09-09 at 14:19 +0300, Michael Tokarev via samba-technical
> > > 
> > > wrote:
> > > > I'm not sure if this matter or not (since ldb is tied with samba), but
> > > > ldb in 4.17.0rc5 lacks versions 2.5.1 and 2.5.2 released within samba
> > > > 4.16.x series, while previous minor ldb releases are listed there.
> > > 
> > > No, we don't normally include the branched history of ldb there.
> > 
> > Maybe this is something which can be reviewed?
> > 
> > The thing is.  Giving this ldb-2.5.2 version as an example.
> > 
> > Let's imagine there's a program using ldb (linking with ldb).  And it
> > has been compiled with ldb-2.5.2.  And it uses, say,
> > ldb_msg_add_string_flags symbol.  When compiled/linked against ldb-2.5.2,
> > the executable is marked with NEEDS: ldb_msg_add_string_flags at LDB_2.5.2,
> > and generally needs LDB_2.5.2 version in libldb.
> > 
> > Now we upgrade libldb from 2.5.2 to 2.6.1. But there, the same
> > ldb_msg_add_string_flags is versioned as LDB_2.6.1. But it is the
> > same symbol, doing exactly the same thing.
> > 
> > So this program which were linked with ldb-2.5.2, will not run after
> > upgrade. - runtime linker will complain it can't find LDB_2.5.2 version
> > (and this symbol) in just-upgraded ldb-2.6.1.  So we'll have to
> > recompile the program just to fix the ldb versioning references.

Urgh.  That is awkward.  

The challenge is that, as you know, this came in during a security
release, where we are normally trying not to bring in other unrelated
changes (so don't just backport the 'future' changes from master). 
This is why we branched out the version numbers in the first place. 

> > Maybe for ldb this is more theoretical, since main its user is samba,
> > and as far as I can tell, samba should use exactly the same version of
> > ldb at runtime as it were compiled with.  In debian we do have this
> > requirement now, - maybe someday it can be lifted, I dunno.  But for
> > other libraries this might be more interesting.
> 
> I argued with this many times, but libldb is simply not a stable API and it 
> should have never been released as a public library.

I tend to agree.  

If I find some time at least I'm keen to try yet again (as I've had
some discussions to suggest an emerging consensus) to at least make ldb
an output of the Samba build (like libwbclient).   That doesn't solve
the full problem at all, but starts the walk backwards as far as we can
right now.  

> The problem is that as it has been released and others started to use it (e.g. 
> sssd). So whenever you update ldb you always have to recompile all projects 
> depending on it.

I think that matches the actual promises Samba has the resources to
offer in this area.  

> In RHEL we have marked libldb as ACG level 4
> https://access.redhat.com/articles/rhel8-abi-compatibility

Very wise.

Andrew,

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