[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3FDF4A12.9050204@mvista.com>
Date: Tue, 16 Dec 2003 12:08:18 -0600
From: Mark Hatle <fray@...sta.com>
To: xvendor@...ts.openwall.com
Subject: Re: Berkeley DB versions
Andreas wrote:
> Hi all, I hope this list is still alive and with subscribers :)
Yup.. at least I'm still alive and subscribed.. ;)
> 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
This has been a major pain in the ... for us..
> 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:
That is basically what we have done.. we only ship one version of db.
And we obsolete any previous versions.. 4.1.25 I think we what we ship...
> - -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.
Again that is one of the things we do. Luckily either the apps that
need db (rpm) provide it themselves, or were easily patched to the use
the version we supply. (Luckily for me we have a "small" distribution
compared to most folks..)
> - /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?
We renamed _ALL_ fo the libdb files to be increditbly excplicit.. as
well as ensure the soname stuff is properly in the package.. This has
eliminated a lot of compatability issues.. (luckily).
> - 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?
We dumped it a while back (2+ years?) and so far not a single complaint
from our customers/users.. IMHO anything still using db1 needs a
serious overhaul..
I doubt any of the above helps for your situation.. but rest assured you
arn't alone in your pain.. ;)
--Mark
Powered by blists - more mailing lists
Please check out the
xvendor mailing list charter.
