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

Alexander Bokovoy ab at samba.org
Mon Apr 8 09:15:58 UTC 2019


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.


-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list