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

[Nico Kadel-Garcia]

On Sat, Sep 10, 2022 at 4:45 PM Andrew Bartlett via samba-technical
<samba-technical at lists.samba.org> wrote:
>
> 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-
>
> > > 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.

It specifically messes with the update to samba 4.16 or samba-4.17 for
RHEL libndr.so, for example, has a conflicting version used by
/usr/lib64/libndr.so.3 versus /usr/lib64/libndr.so.3 for the older
samba-client-libs originally published for RHEL 8 and RHEL 9. I don't
even try to backport to RHEL 7 anymore due to the gnutls dependency
stack.

Now, me? I kick sssd to the curb as fast as I can on RHEL based
setups, for a whole stack of reasons, I'll refrain from explaining
here. But since Red Hat's own documentation on joining domains refers
extensively to sssd, using a more contemporary Samba instead is
expensive in meetings and manpower.

Nico Kadel-Garcia


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