tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

simo idra at samba.org
Thu May 10 06:35:07 MDT 2012


On Thu, 2012-05-10 at 14:38 +0930, Rusty Russell wrote: 
> On Wed, 18 Apr 2012 22:26:37 +1000, ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
> > > +1.
> > >
> > > Or just break the back compatibility, and go straight against TDB2.
> > >
> > > I'd like Rusty to have a bit to think here, there may be things he can do
> > > much better when freed from a few pieces of the API/ABI.
> > >
> > 
> > Agree. Lets break back compatibility.
> > We need TDB2, but we need a the best TDB2 we can get.
> > Lets not cripple it by imposing semantics or restrictions from the
> > TDB1 API we want to break from.
> > 
> > A new api, a new namespace, a new clean start.
> 
> You misunderstand.  That's what we did: completely disregard the tdb1
> API.  In some cases it turns out to be a trivial conversion, in others,
> it's completely different (hence tdb_compat, to paper over it for the
> transition).
> 
> We *didn't* rename everything though.  That helps in transition, but is
> clearly ugly in the years ahead.
> 
> Since the transition is taking longer than we'd hope (and turning tdb2
> off again as proposed by Christian isn't going to help), perhaps we
> should change this and rename everything to tdb2*.  It's not *that* big
> a change to SAMBA in practice.

Rusty,
it is a big change for external users of tdb.
Distributions ship tdb1 as a standalone library. If you force only tdb2
and at the same time you do not rename all the symbols and force API
changes you are putting distributions between a rock and a hard place.

I really think we should change API signatures so tdb1 and tdb2 (or
whatever we want to call it) can be installed side by side for a while
until all users decide to abandon tdb1 and we can kill it.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>



More information about the samba-technical mailing list