Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Dec 2003 13:39:15 -0200
From: Andreas <>
Subject: Berkeley DB versions

Hi all, I hope this list is still alive and with subscribers :)

I was wondering what all vendors are doing regarding this topic: all
the different berkeley db versions lying out there.

We, for example, have:

Prior to db 4, it's sort of a mess, with different naming schemes for
the dynamic libraries and include files.

Starting with DB4 (I obsoleted db < 4 for now, more on it later), I'm
using /usr/include/db{4,4.1,4.2} for the include files and I'm experimenting
with /usr/lib/db4.2 for the 4.2 libraries. Here are some thoughts that are
going through my head:

- -ldb: many aplications rely on the concept of a "default db library". I
asume this is for historic reasons. I would like to get rid of this if possible. Same
for /usr/include/db.h, which is usually a symlink to /usr/include/db<version>/db.h.
Applications which use #include <db.h> will still build if one adjusts the include
path, which is what I'm doing.

- /usr/lib/ argh, it's the same name for db4, db4.1 and db4.2. I used
to remove these ambiguous files from our packages, but if I decide to go the
/usr/lib/db<version> way then I could leave these files there. Or not?

- for some reason, db libraries have this different naming convention: instead of
the usual (at least for me), they are
I gave up wrestling with that to some extent, I only take care to not have
conflicting names (like

A colleague of mine hinted that we should at least still have db1, which is sort
of a standard. I know that I need to have it in order to build the famous
dump185 utility. Now, there is also glibc, isn't there? Doesn't it also use db? What
about hashed /etc/passwd.db files? Is it a completely different animal?

Sorry for the long email, and thanks for any hints

Powered by blists - more mailing lists

Your e-mail address:

Please check out the xvendor mailing list charter.