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

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 07:28 PM, tridge at samba.org wrote:
> Hi Stephen,
> 
>  > 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.
> 
> Can you explain that a little more? The command "make dist" should
> work in each library subdirectory to create a release tarball. I've
> just tested that for talloc, tdb, tevent and ldb on my system and it
> worked fine. If there is a problem with it then we certainly need to
> fix that.
> 
> Here are some additional notes about "make dist" that you may find
> useful:
> 
>  1) the waf build system looks for a file called .lock-wscript to find
>     the top of the build directory. If you have a completely clean git
>     tree, and run "make dist" it will not work, as it will fail to
>     find the root directory to run it. You can fix this either by
>     running ./configure first, or just do "touch .lock-wscript" before
>     you run "make dist". You should remove that .lock-wscript
>     afterwards as it would interfere with normal build (an empty
>     .lock-wscript is not valid for a normal build, it just happens to
>     work for 'make dist').
> 
>     I'll have a look at making "make dist" work without a
>     .lock-wscript file to make this a bit easier.
> 
>  2) the resulting tarball from "make dist" will be self contained. It
>     will contain all the dependent libraries and the build system
>     files as well as the library you are building. So for example if
>     you do "make dist" in source4/ldb you end up with a tarball
>     ldb-0.9.22.tar.gz which contains a copy of the ldb tree, plus
>     these additional directories:
> 
>       ldb-0.9.22/buildtools/*
>       ldb-0.9.22/lib/replace/*
>       ldb-0.9.22/lib/talloc/*
>       ldb-0.9.22/lib/tdb/*
>       ldb-0.9.22/lib/tevent/*
> 
>     The resulting tarball should be exactly what you need to include
>     in the SRPM for ldb. You don't have to use those included
>     libraries of course, and you can use configure options to control
>     whether to use the bundled libraries or not, but the tarball
>     should contain everything that is needed to build ldb regardless
>     of what combination of system libraries you choose to use.
> 
>  3) These is a command "make distcheck" that will test that the
>     tarball is complete. It creates the tarball, then unpacks it in a
>     temporary directory, then runs a configure, build and install in
>     that directory.
> 
>  > 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.
> 
> Can you try the above commands and see if these is any problem with
> them for you?
> 
>  > 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
> 
> before we consider those sorts of solutions, I'd like to first
> understand why what we have now is not working. 
> 
> Cheers, Tridge


Thanks for the responses. First of all, yes. We were trying to go
through the make dist process incorrectly, which was part of our
problem. I've still discovered another bug in that process that I'll be
filing later, but otherwise that does seem to work for us.

Please see the reply I made to Andrew Bartlett's comments on this
thread. I had a discussion about this in #samba-technical on Friday and
came up with a modified proposal (that does not involve separating these
libraries from the Samba source, but does involve more regular tarball
releases).


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0q+9YACgkQeiVVYja6o6PGngCgovss5npL7z14/2TlJQVbAyx/
zFkAoIMJOPKf5TfpnzqM36vWJMuY+dTW
=3rG0
-----END PGP SIGNATURE-----