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

[Simo]

FWIW I am against this, not only we went down this road because
breakage was too painful for downstreams before, it also was useful to
reduce dependencies for projects that used nothing else.

The other reason was to force ourselves to keep it more stable, this
was done for both internal and external reasons, it would force us to
reason more carefully about changes to a core component.

I think you got valuable contributions because of this, as the
downstream projects provided not only feedback but also direct code
contribution.

Simo.

On Mon, 2019-04-08 at 15:26 +1200, 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?
> 
> Metze,
> 
> You might want to hold off producing the tarballs until we decide this.
> 
> Thanks!
> 
> Andrew Bartlett