tdb_chainlock() in tdb1, tdb2 and tdb_compat ?
ira at samba.org
Mon Apr 16 04:58:56 MDT 2012
On Fri, Apr 13, 2012 at 6:29 PM, Andrew Bartlett <abartlet at samba.org> 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,
> > 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