tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

Ira Cooper ira at
Mon Apr 16 04:58:56 MDT 2012

On Fri, Apr 13, 2012 at 6:29 PM, Andrew Bartlett <abartlet at> wrote:

> So, what would it take to instead release a tdb2 based autoconf build
> for the file server?  If these things are indeed 'very important', and
> we only want to do the flag day pain once, then perhaps someone who is
> familiar with the autoconf build system could switch that to using an
> internal build of tdb2, or the system tdb2 when it becomes available?

I can do that internally with the toplevel.  I remember that I went back to
autoconf on master... but I need to track down why.  I don't remember if it
was symbols issues, or real issues... At that moment, I had other things to
work on... Alas, my manager won't like me losing 2-3 weeks to the build

This would ensure we only have one tdb API and ABI that we care about,
> which would be a very good thing.

If it suits the projects needs.  Yes.  But that caveat applies to just
about everything in my mind.

> We already build and test the top level code with tdb2, so there is good
> reason to think that the porting work is complete, and we have some
> confidence in the code due to it being part of autobuild.

I've had code "pass testing" and fail in production plenty of times.  See
where I switched off waf again.  I need to track it down when I'm back to
Samba work again.

> > > I think we should move to tdb2 eventually, but trying to support both
> > > tdb1 and tdb2 does add a fair bit of complexity (in terms of
> > > the build system and other code) with no huge gains at this
> > > point. We seem to have enough distractions for 4.0 as is.
> > >
> >
> > I think we should look at our requirements, and decide how to best meet
> > them.  Sometimes there isn't a 1 size fits all solution.
> >
> > In the end, I don't care what we choose, as long as the pain goes away,
> and
> > there is a TDB to do forward development on.
> The current situation is clearly unacceptable in the long term, and is
> becoming unacceptable in the short term.  Having spent a little time
> dealing with the build system issues (on the waf side), we are now down
> to the more fundamental issues (which is why I tried to remove what
> distractions I could).

I would like us to make a decision on this:
>  - after rusty has had a chance to comment and
>  - before SambaXP
> because I still hold onto the faint hope of doing some kind of beta
> release at SambaXP, if I can coax s3fs into a little more life.

Good luck with the release.



More information about the samba-technical mailing list