[ldb] Re: Moving basic libs to a new repo and release them as a separate package

Jelmer Vernooij jelmer at samba.org
Fri Feb 24 08:13:16 GMT 2006


On Fri, Feb 24, 2006 at 04:45:12PM +1100, tridge at samba.org wrote about '[ldb] Re: Moving basic libs to a new repo and release them as a separate package':
> I certainly like the idea of promoting these components of Samba more
> outside of the Samba project, which is why I created
> http://ldb.samba.org and http://talloc.samba.org, and I'd like to see
> much more done like this.

> My only concerns on how we do this are purely practical
> ones. Specifically:

>  - I seem to remember some problem with svn:externals and ethereal
>    sharing pidl. Am I remembering that correctly? Was this solved?
Their problem was the fact that people who were behind a very
restrictive firewall could check out the ethereal source (because they
use webdav, e.g. http://svn.ethereal.com/trunk/) and pidl was using
the native SVN protocol (svn://svn.samba.org/...) which was being
blocked by their firewall. This would not be an issue for us as we're
already using the native svn protocol for everything.

One of the things that might be a concern though is the fact that the
URLs to the libraries in SVN are different for 'regular' users and
people with commit access (regular users have svn://, developers have 
svn+ssh://). Since we don't want to lock out users who do a checkout, we'll 
have to set the svn:externals to the svn:// URL, meaning we can't do
commits in svn:externals trees.

We could also use robert collins' config-manager tool to checkout a whole 
bunch of different directories. This does mean requiring another tool for
checking out the source tree.

Either way (even with svn:externals), we'll have some sort of
top-level configure script that runs configure in the directories of
all the libraries and recursive make. I don't think that would be too
bad.

>  - actually having the exact same source repository for some libs
>    between Samba3 and Samba4 might prove problematic, as it means that
>    checkins in one tree could break the other, so it raises the burden
>    of testing. With the manual merge we have the opportunity to
>    identify these things and fix them.

> The 3rd problem might not be significant for talloc, which has a
> pretty well defined API by now, but it could well be tricky for
> tdb. We have historically done quite a few hackish things (such as the
> alarm timelimit code) in tdb that could well break the other tree.
All three libraries have their own (seperate) testsuites and (should)
have a stable API. In case of optional features, we could simply add a
configure flag and not that from both branches.

> I think that we should have official releases of these packages
> though. So it would be good if users could download ldb-1.0.tar.gz
> somewhere, and talloc-1.0.tar.gz. Even better if the distros pick
> these up.
It would be very nice to see that, indeed. 

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20060224/52b2309e/attachment.bin


More information about the samba-technical mailing list