gmane.comp.misc.xvendor

Andreas | 15 Dec 16:36

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

(Continue reading)

headers

Ademar de Souza Reis Jr. | 16 Dec 16:51

Re: Berkeley DB versions

On Mon, Dec 15, 2003 at 01:39:15PM -0200, Andreas Hasenack wrote:
> 
> - 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).

People should read the "Program Library HOWTO":
http://www.tldp.org/HOWTO/Program-Library-HOWTO/

--

-- 
Ademar de Souza Reis Jr. <ademar@...>

^[:wq!

headers

Mark Hatle | 16 Dec 19:08

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...

(Continue reading)

headers

Andreas | 16 Dec 20:47

Re: Berkeley DB versions

On Tue, Dec 16, 2003 at 12:08:18PM -0600, Mark Hatle wrote:
> >- -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 

So, have you removed the concept of a default db library (-ldb) or does
it just work for you because you only ship one version?

I'm very tempted to remove /usr/lib/libdb.so and /usr/include/db.h and
patch any app that breaks due to this and make it use an explicit db
version.

> I doubt any of the above helps for your situation.. but rest assured you 
> arn't alone in your pain.. ;)

It does help knowing that :)

headers

Mark Hatle | 16 Dec 21:24

Re: Berkeley DB versions

Andreas wrote:
> On Tue, Dec 16, 2003 at 12:08:18PM -0600, Mark Hatle wrote:
> 
>>>- -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 
> 
> 
> So, have you removed the concept of a default db library (-ldb) or does
> it just work for you because you only ship one version?

It just happens to work as an artifact of one version.  However, very 
few things in our stuff use -ldb.. and we have removed usages of it in 
the past stop an app from using db.

> I'm very tempted to remove /usr/lib/libdb.so and /usr/include/db.h and
> patch any app that breaks due to this and make it use an explicit db
> version.
> 
> 
>>I doubt any of the above helps for your situation.. but rest assured you 
>>arn't alone in your pain.. ;)
>

(Continue reading)

headers

Solar Designer | 26 Dec 01:41

Re: Berkeley DB versions

Hi,

On Mon, Dec 15, 2003 at 01:39:15PM -0200, Andreas wrote:
> I hope this list is still alive and with subscribers :)

There're 34 subscribers currently, from around 12 different vendors/teams.

I'm sorry you didn't get many responses for your query, -- perhaps
it's not so trivial.

--

-- 
Alexander Peslyak <solar@...>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments