Proposal: Split libtalloc, libtdb, libtevent and libldb into a separate upstream project

Andrew Bartlett abartlet at samba.org
Fri Jan 7 14:58:36 MST 2011


On Fri, 2011-01-07 at 09:50 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> First, please allow me to introduce myself. My name is Stephen
> Gallagher, and I am the lead developer at Red Hat on the System Security
> Services Daemon.
> 
> For some time now, Samba has ceased to be the only project relying on
> the libtalloc, libtdb, libtevent and libldb libraries. For example, SSSD
> relies heavily on all four of these libraries, and some of the FreeIPA
> subprojects such as certmonger do as well.
> 
> The problem we have right now is that, as they are currently developed,
> it is prohibitively difficult to get release tarballs created for these
> packages in a timely manner. For example, the most recent version of
> libldb available in Fedora is 0.9.10, because libldb is only included in
> the Samba tarball.
> 
> Furthermore, as Simo discovered today, with the change to the new WAF
> build-system, it is no longer a simple matter to extract the sources for
> these libraries to do an independent tarball release.
> 
> So what I would like to see is for the samba project to split these
> libraries off into their own upstream project and git repository, where
> development of these libraries can happen in parallel to Samba
> development (and with the assistance of the SSSD development team, as
> well). The main Samba project would need to be modified slightly to
> ensure that it can use a system-installed version of these libraries
> instead of carrying them along itself.
> 
> This would be advantageous because upstream releases of these libraries
> could be scheduled independently of Samba itself, to meet the needs of
> both Samba and non-Samba dependent projects.

I understand your concern, but I don't see how this change would help us
or your use of our subprojects.  You raise two quite valid points:  That
there may be issues in creating the tarballs for the subprojects, and
that releases of these projects are infrequent. 

For the tarball issue, if 'waf dist' in each subproject does not produce
a tarball for that subproject, then this is a bug, which can and should
be dealt with separately. 

However, I don't see how creating a separate upstream project for these
libraries would help anybodies interests.  The releases would continue
to be as infrequent as they currently are, because nothing in this
proposal would make them more frequent.  These libraries are developed
first and foremost for Samba itself.  It's great that they are useful to
others, but we must not loose sight of their first purpose, as that is
what is keeping them maintained and useful.  To split these out into a
different GIT tree would make our development more difficult, removing
the ability to add features and rely on them directly, or requiring us
to manually bundle them anyway.  

It is important to realise that ldb and the modules form the core of the
Active Directory engine in Samba4.  It's exact behaviour and semantics
(including those not publicly exposed) are vitally important to our
mission as an AD domain controller. 

The last time one of these subprojects was spun off into a separate
subproject was tdb, which was launched onto sourceforge, but did not
make it's own way very well.  Real tdb development still happened in
Samba, and the sf.net project languished.  Eventually we brought that
back 'in house' by working with Debian (the only packager of the sf.net
version) to just package it from Samba. 

We would also loose the benefits of using the same waf build system,
which has for example brought proper, automatic symbol versions to the
subprojects.

While in a package management system is is easy to say that a project
should rely on these prerequisite packages, we have endeavoured to make
Samba as easy to install as possible, and so far that has included
having as few dependencies as possible.  Even depending on a wide range
of python versions has been a controversial step for us. 

For your use of newer unreleased versions of Samba subprojects, I
suggest that you may wish to follow jelmer's example in Ubuntu, where he
currently packages the GIT snapshots to allow Samba4 to depend on
'system' (rather than bundled) versions of the subproject packages. 

We can of course discuss releasing these packages more often, but it's
actually the devolution of the maintainer-ship that has made this more
difficult.  When I last discussed this with Jelmer (Samba4 release
manager), he didn't feel comfortable blessing a tdb release for each
Samba4 alpha release, as he isn't the tdb maintainer (that's rusty's
job).  But at the same time, we have enough trouble getting Samba alpha
releases made, that he didn't fancy getting the prerequisite packages
released by their maintainers first.  The same would apply for ldb and
talloc etc. 

Finally, you suggest that the SSSD team could assist with ldb
development.  We would of course welcome your assistance.  We also
appreciate you raising this issue, it is important to understand what
our library users need, and hope we can find a mutually satisfactory
improvement to our processes. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.



More information about the samba-technical mailing list