[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