[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20031215153915.GD22719@conectiva.com.br>
Date: Mon, 15 Dec 2003 13:39:15 -0200
From: Andreas <andreas@...ectiva.com.br>
To: xvendor@...ts.openwall.com
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:
1.85
2.4.14
3.1.17
3.3.11
4.0.14
4.1.25
4.2.52
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/libdb-4.so: 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) libfoo.so.major.minor, they are libfoo-major.minor.so.
I gave up wrestling with that to some extent, I only take care to not have
conflicting names (like libdb-4.so).
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
Please check out the
xvendor mailing list charter.
