[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New project goal: Get rid of Berkeley DB (post jessie)



On Thu, Jun 19, 2014, at 18:08, Colin Watson wrote:
> On Thu, Jun 19, 2014 at 07:10:46AM -0700, Russ Allbery wrote:
> > We would need to continue to support it in Debian for reading existing
> > Berkeley DB key/value pair databases via such things as Perl's DB_File.
> > I know I'm not the only one who has tons of key/value pair Berkeley DB
> > files scattered around from inumerable pieces of local code or packages
> > like krb5-strength.
> > 
> > That said, I don't think the Berkeley DB key/value pair on-disk data
> > structure could be all that complex, the algorithms around such a thing
> > are very well-understood, and I don't think the implementation has changed
> > in years and is therefore unambiguously under a good license.  Maybe
> > someone could fork just this portion of Berkeley DB without all the
> > complex transaction stuff and take over upstream maintenance of just that?
> 
> Right.  I think for many of the affected packages, given some upstream
> cooperation, it would be quite easy to convert them over to maybe
> something as simple as gdbm; I did that many years ago for man-db after
> getting fed up with on-disk format changes and other complexity-induced
> bugs, and have not been at all sad that I did so (this was well before
> the licence change, which I have not thought very deeply about).

True, but gdbm is GPL and LGPL and that's a problem for many non-GPL
applications using Berkeley DB now.

qdbm with LGPL might be a better match, but I think that LMDB API was
designed for easy porting from Berkeley DB, so it's my favourite
candidate.

> But I'm not sure that it would be helpful to be aggressive about
> removing Berkeley DB entirely; in the medium term I think the best we
> could hope for would be to reduce the extent to which it is entrenched.

My vision of "aggressive" in context of Debian release goals is
something like
10 years :). And we should coordinate the transition with upstream and
probably also other distributions.

Berkeley DB 6 is also no-flyer for RH, so the move to something else
might
work across all distros.

O.
-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


Reply to: