On Wed, Apr 02, 2003 at 09:21:04AM -0500, Greg Troxel wrote:
> NetBSD and FreeBSD have db 1.85 as part of the base system.
> 
> There is also gdbm, which provides db compatibility and a similar
> interface.  It happens to be installed on my system and is required by
> sawfish/librep.
> 
> My system also has sleepycat db3 installed, required by a lot of gnome
> stuff.

Yes, 1.85 is a stable and efficient library for simple hash and btree
databases/lookup tables. The only 'significant' complaint I've ever
heard about it is that it can't deal with multiple threads. Both the
code and the existing API are thread unfriendly. This is ofcourse no big
deal for Coda, as we use cooperative threading instead of concurrent
(kernel) threads.

Gdbm would definitely have been my second choice (and not just because
someone we all know wrote it :) But the on-disk files couldn't be moved
reliably between heterogeneous systems.

Sleepycat is at db4, or ehh, no db4.1 by now. My system actually at the
moment _needs_ db2, db3, db3.2, db4, and db4.1 because some applications
linked to the one and others to the other. Traditionally this major
number is bumped only when there are incompatible API differences, but
maybe they are trying to catch up with the windows version numbers.

> would have the advantage of not having more code to maintain and
> perhaps having a standard on-disk format that could be read by perl

The CPAN package is called CDB_File, there are python, ruby, java and
lua interfaces as well.

    http://cr.yp.to/cdb.html

> etc.  db3 is pretty large, though, but it's not like coda servers are
> small already.

Hmm, interesting, a stripped codasrv binary is about the same size as
libdb3, but libdb4 is getting a bit smaller again. They probably got
sick from all the complaints about how big it was.

> Sorry to be difficult, but I don't see why this is hard.
> <flamebait>Are the mainstream Linux distributions really this
> broken?</>

Not really, nobody 'maintains' db 1.85, as such it will never get fixed
for threading issues or whatever other problems people might have with
it (i.e. the distribution vendors can't blame someone else for bugs). In
the mean time sleepycat's db is a standard part of glibc and has some
sort of 'compatibility glue' so that old apps can be linked with db2/3/4
So we still have the stable API, but the on-disk format is different.
Which is pretty annoying if the SCM is using db4.1 and the other servers
are a mix of servers linked against db1.85, db2 and db3.

> And I noticed your post was 4/1, but I've been hearing db1.85
> rumblings for a long time.

Sorry, no joke ;)

Jan