why does samba build system versions all public-lib symbols?

[Andrew Bartlett]

On Sat, 2023-09-09 at 13:57 +0300, Michael Tokarev via samba-technical
wrote:
> Hi!
> 
> I grumbled on this list before about ABI symbol versioning in samba
> public libs
> already.  Here comes a question, finally: why?

Three reasons, as I understand it.

Firstly, we were told by good and knowledgeable people from the
distribution community that it was the "right thing to do".  Samba
never used to provide public libraries, other that libsmbclient, and we
were trying to grow up as a project and do things right. 

There was a push at the time for the 'subprojects' to grow their own
wings and move out of the monorepo.  We have a bit of this with the
wrapper projects that Andreas maintains, but these are less impactful
on a distribution as they are only needed for testing. 

Secondly, to in conjunction with -rpath, to allow co-installation of
Samba on a system that may have an existing Samba, to ensure we linked
to the correct talloc, tevent etc.  We have had various issues with
cross-linked Samba over the years, and some of the behaviour is hard-
won.

Thirdly, at the time, the public libraries were thought to be
monotonically increasing in master, with very few changes in older
versions and certainly none that would change symbols. 

LDB
---

LDB is not suitable to be a public library on any of these measures.

It is used rarely outside Samba, it is developed and maintained as part
of Samba and backported as part of Samba.  Security releases regularly
require adding to the ABI, and development would be aided greatly if we
could break it more often. 

It should be released from the current release series, with
monotonically increasing versions and no backports for use by sssd, but
Samba should never consume this, and Samba backports should use the
internal ldb with private symbols. 

I would very, very gladly review and champion an effort to try again. 

This might avoid the push-back we previously got (I wanted to remove
the ldb releases and independent build system entirely).

> Most often this becomes problematic when back-porting some symbol
> changes
> (usually newly added symbols) from current "mainline" branch to
> previous
> branches, sometimes multiple.
> 
> For example, ldb 2.8.0 introduced ldb_msg_add_distinguished_name()
> and a
> few others, while trying to fix an issue.  Current samba (4.19) uses
> this
> symbol.  When built against current ldb 2.8.0, this symbol will be
> tied
> to version 2.8.0.  Okay, so far so good.
> 
> This same symbol has been back-ported to previous ldb release,
> introduced
> in 2.7.2 version, and is used by samba 4.18.1.  So when samba 4.18.1+
> is
> built against ldb-2.7.2 which comes with it, it will be linked to
> ldb_msg_add_distinguished_name at LDB_2.7.2, instead of
> ldb_msg_add_distinguished_name at LDB_2.8.0, despite the fact this is
> exactly
> the same function.
> 
> So when I have, say, samba 4.18.4 installed, I can not upgrade ldb to
> version 2.8.0, since this will break samba due to missing symbol of
> version 2.7.2.
> 
> But it is more: the same symbol ldb_msg_add_distinguished_name has
> been
> back-ported to samba 4.17 too, which comes with ldb-2.6.2.  And
> there,
> it is named ldb_msg_add_distinguished_name at LDB_2.6.2 instead.  Which
> is
> 3rd name of the SAME symbol.  And I can't update libldb from 2.6.2 to
> neither 2.7.2 nor 2.8.0, since this will obviously break samba.
> 
> Right now I have ldb-2.8.0 in debian, with 
> ldb_msg_add_distinguished_name at LDB_2.8.0,
> and samba 4.19.0 linked to it.  I can't re-build ldb with added sigs
> file
> from version 2.7.2 or 2.6.2 without recompiling all deps.  So I'm,
> once
> again, in a catch-22 situation, to decide which part to break.
> 
> Even if these symbols are only used by samba itself, - based on which
> I
> can have strong versioned (=binary:Version) dependency between samba
> and
> ldb packages, - this is possible because both are now built from the
> same
> source, - but these symbols are still part of public ABI, and other
> software
> *might* (start) using these symbols, and will be broken by each samba
> upgrade.
> 
> So the question is: why to mark symbols with versions at all, why
> can't
> these be unversioned like almost all other software does?  What good
> such versioning serves?

I've followed your various pleas here and I cannot but agree.

> I looked at the build system, - buildtools/wafsamba/samba_abi.py -
> where
> it generates the ld script file. I'm about to drop the whole thing in
> there for debian and use manually crafted symbols vile instead, to
> fix
> this whole issue.  But even there I'll have to perform some sort of
> transition from versioned to unversioned, or somesuch..

We were trying to be 'good, well behaved' software, and follow
distribution policies and guidance. 

It would break distribution policies of not bundling, but I would:
 - release ldb versions for sssd, with versions.
 - *never* allow Samba to link to a system ldb. 

How we deal with the ldb tools I'm not sure however.  Does sssd use and
administration require them?  Would 'alternatives' be over the top?

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