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

Andrew Bartlett abartlet at samba.org
Wed Apr 10 19:36:40 UTC 2019


On Mon, 2019-04-08 at 13:11 +0200, Andreas Schneider wrote:
> 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.

I'm sorry, can you be more specific?

> > 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.

Perhaps.  However the changes that have caused the most need to avoid
version skew have not been those addressing new things, but fundamental
mis-features from the very earliest days of ldb.  

I spoke on this at the linux.conf.au sysadmin miniconf in 2018:
https://sysadmin.miniconf.org/2018/lca2018-andrew_bartlett-fixing_tridges_mistakes-taking_samba_ad_to_scale.pdf
https://www.youtube.com/watch?v=JNR8bJkWCjA

I've lost the keys to the TARDIS, do you have them?

> 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

The biggest ABI-breaking changes that have been:

Samba 4.7 - per-search locking was missing/added at the ltdb layer
Samba 4.9 - pre-search locking was missing/added at the ldb layer
(protecting the module stack).

Samba master - change to a public structure

I'm not sure how any of these could have been handled, even at great
engineering cost, via symbol versions.  

Beyond that, the fundamental challenge is that currently the ldb
version is changed, and metze diligently tags a relaese for every minor
ABI change.  

As I mention above:
 - ldb for Samba is tested as a whole as part of Samba, and we rightly
banned mixing ldb/samba versions due to the result being untested.
 - ldb is made stable by the same process as the whole of Samba.  The
intermediate releases, forced by an ABI change, are not helpful to
users and are actively harmful for packaging teams, so we should not
provide them.

Finally, to address Simo's point about external contributions, I wish
it were so.  Sadly for as far as I can determine contributions to ldb
have been almost exclusively for:
 - Samba's AD DC by members of the Samba team
 - the unit tests by Jakub Hrozek
 - python3

The contributor histogram for all time and the last four years is
attached,  I may be missing something.

I also don't see how the smaller tarball assists these in any case, the
independent build system and ABI checks are still being maintained (as
per ctdb) and all contributions have to go via CI and autobuild on the
full git repo anyway.

Clearly I'm missing something:  Can you spell our more clearly how you
see the production of the independent tarball at essentially random
development intervals assisting ldb development?

Thanks,

Andrew Bartlett


-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba


-------------- next part --------------
      1 Author: Alexander Bokovoy <ab at samba.org>
      1 Author: Bernd Kuhls <bernd.kuhls at t-online.de>
      1 Author: Björn Baumbach <bb at sernet.de>
      1 Author: Björn Jacke <bj at sernet.de>
      1 Author: David Disseldorp <ddiss at suse.de>
      1 Author: David Mulder <dmulder at suse.com>
      1 Author: Ian Stakenvicius <axs at gentoo.org>
      1 Author: Jelmer Vernooij <jelmer at jelmer.uk>
      1 Author: Jeroen Dekkers <jeroen at dekkers.ch>
      1 Author: Kelly Yeoh <kyeoh at au1.ibm.com>
      1 Author: Marc Muehlfeld <mmuehlfeld at samba.org>
      1 Author: Nadezhda Ivanova <nivanova at symas.com>
      1 Author: Pavel Reichl <pavel.reichl at redhat.com>
      1 Author: Petr Cech <pcech at redhat.com>
      1 Author: Samuel Cabrero <samuelcabrero at kernevil.me>
      1 Author: Stephen Gallagher <sgallagh at redhat.com>
      1 Author: Thomas Nagy <tnagy at waf.io>
      1 Author: Timur I. Bakeyev <timur at freebsd.org>
      1 Author: Uri Simchoni <uri at samba.org>
      1 Author: Vadim Zhukov <persgray at gmail.com>
      2 Author: Christian Ambach <ambi at samba.org>
      2 Author: Ira Cooper <ira at samba.org>
      2 Author: Lukas Slebodnik <lslebodn at redhat.com>
      2 Author: Ralph Boehme <slow at samba.org>
      2 Author: Timur I. Bakeyev <timur at iXsystems.com>
      3 Author: Howard Chu <hyc at symas.com>
      3 Author: Lukas Slebodnik <lslebodn at fedoraproject.org>
      4 Author: Rusty Russell <rusty at rustcorp.com.au>
      4 Author: Tim Beale <timbeale at catalyst.net.nz>
      6 Author: Aaron Haslett <aaronhaslett at catalyst.net.nz>
      6 Author: Adrian Cochrane <adrianc at catalyst.net.nz>
      6 Author: Andrej Gessel <Andrej.Gessel at janztec.com>
      6 Author: Mathieu Parent <math.parent at gmail.com>
      7 Author: Amitay Isaacs <amitay at gmail.com>
      8 Author: Jeremy Allison <jra at samba.org>
      9 Author: Kamen Mazdrashki <kamenim at samba.org>
      9 Author: Michael Adam <obnox at samba.org>
     13 Author: Jakub Hrozek <jakub.hrozek at posteo.se>
     14 Author: Karolin Seeger <kseeger at samba.org>
     14 Author: Noel Power <noel.power at suse.com>
     15 Author: Joe Guo <joeg at catalyst.net.nz>
     17 Author: Andreas Schneider <asn at samba.org>
     18 Author: Jelmer Vernooij <jelmer at samba.org>
     19 Author: Matthieu Patou <mat at matws.net>
     22 Author: Petr Viktorin <pviktori at redhat.com>
     25 Author: Volker Lendecke <vl at samba.org>
     26 Author: Matthias Dieter Wallnöfer <mdw at samba.org>
     28 Author: Andrew Tridgell <tridge at samba.org>
     35 Author: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
     37 Author: Garming Sam <garming at catalyst.net.nz>
     56 Author: Stefan Metzmacher <metze at samba.org>
     75 Author: Gary Lockyer <gary at catalyst.net.nz>
    263 Author: Andrew Bartlett <abartlet at samba.org>
-------------- next part --------------
      1 Author: Alexander Bokovoy <ab at samba.org>
      1 Author: Bernd Kuhls <bernd.kuhls at t-online.de>
      1 Author: Björn Baumbach <bb at sernet.de>
      1 Author: Björn Jacke <bj at sernet.de>
      1 Author: David Mulder <dmulder at suse.com>
      1 Author: Ian Stakenvicius <axs at gentoo.org>
      1 Author: Ira Cooper <ira at samba.org>
      1 Author: Jelmer Vernooij <jelmer at jelmer.uk>
      1 Author: Matthias Dieter Wallnöfer <mdw at samba.org>
      1 Author: Matthieu Patou <mat at matws.net>
      1 Author: Petr Cech <pcech at redhat.com>
      1 Author: Thomas Nagy <tnagy at waf.io>
      1 Author: Timur I. Bakeyev <timur at freebsd.org>
      1 Author: Uri Simchoni <uri at samba.org>
      2 Author: Amitay Isaacs <amitay at gmail.com>
      2 Author: Lukas Slebodnik <lslebodn at redhat.com>
      2 Author: Ralph Boehme <slow at samba.org>
      2 Author: Timur I. Bakeyev <timur at iXsystems.com>
      3 Author: Lukas Slebodnik <lslebodn at fedoraproject.org>
      4 Author: Tim Beale <timbeale at catalyst.net.nz>
      5 Author: Jeremy Allison <jra at samba.org>
      6 Author: Aaron Haslett <aaronhaslett at catalyst.net.nz>
      6 Author: Adrian Cochrane <adrianc at catalyst.net.nz>
      6 Author: Andrej Gessel <Andrej.Gessel at janztec.com>
      6 Author: Mathieu Parent <math.parent at gmail.com>
      6 Author: Michael Adam <obnox at samba.org>
     12 Author: Petr Viktorin <pviktori at redhat.com>
     13 Author: Jakub Hrozek <jakub.hrozek at posteo.se>
     14 Author: Noel Power <noel.power at suse.com>
     15 Author: Joe Guo <joeg at catalyst.net.nz>
     16 Author: Andreas Schneider <asn at samba.org>
     16 Author: Volker Lendecke <vl at samba.org>
     34 Author: Stefan Metzmacher <metze at samba.org>
     35 Author: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
     37 Author: Garming Sam <garming at catalyst.net.nz>
     75 Author: Gary Lockyer <gary at catalyst.net.nz>
    226 Author: Andrew Bartlett <abartlet at samba.org>


More information about the samba-technical mailing list