[PROPOSAL] Re-bundle (stop producing tarballs for) ldb?

[Andreas Schneider]

On Monday, April 8, 2019 11:15:58 AM CEST Alexander Bokovoy via samba-
technical wrote:
> On ma, 08 huhti 2019, Andrew Bartlett via samba-technical wrote:
> > ldb 2.0.0 was marked in master just today, not out of some great
> > fanfare but because an externally exposed API/ABI changed and the .so
> > naming rules require it (as we strictly bind the two things for
> > simplicity).
> > 
> > ldb has been a great project, but aside from sssd and the now defunct
> > openchange, it simply hasn't taken off, certainly not in the way that
> > talloc and tdb have become central parts of the Linux ecosystem.
> > 
> > Samba development and Samba AD DC needs drive ldb, and it isn't going
> > to be an independent project any time soon.
> > 
> > So, I'm wondering if we should stop producing ldb tarballs.  We already
> > have to bump version numbers strictly branch with Samba releases and
> > have complex build logic to ensure we don't build with the wrong
> > version.
> > 
> > For Samba the ABI has always turned our to be a tricky beast, even
> > outside the module stack (where no promies were made) we quickly found
> > that using Samba with the 'wrong' ldb version was just looking for
> > pain.  
> > 
> > After a muck-up where a master version of ldb was published into debian
> > (and so breaking existing setups), our distributors have wondered the
> > same as well.  Specifically I recall a discussion on the debian
> > packaging list about if the ldb package should just be built from the
> > Samba tarball instead.
> > 
> > So this is my proposal: that we build ldb like we build libndr and
> > libsmbclient.  Others can still build against it as a public library,
> > but we never build against a 'system' version.  We should have an
> > option to keep it private as well, just like the current default build.
> > 
> > What do others think?
> 
> Looks like that in the past a need for many breaking changes in libldb
> was driven by an incomplete design of the features for Samba AD.
> Perhaps, spending a bit more effort at a drawing board would have helped
> here rather than shipping and then rewriting the code. I'm trying to
> reflect on this, not blame anyone as one can always find a case where
> own hands were dirty as well.

Also there is a feature on most Unix systems called symbol versioning. With 
this it is even possible to break the API if the library is versioned 
correctly. See:

https://github.com/ansasaki/abimap



-- 
Andreas Schneider                      asn at samba.org
Samba Team                             www.samba.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D