Right now, many packages that need a Berkeley DB end up using the
currently installed db4.

Some packages can define what Berkeley DB implementation(s) work for them
(BDB_ACCEPTED).  And also the pkgsrc user can also pick which Berkeley DB
is the first choice (BDB_DEFAULT).

One problem with this method is when one db library SONAME changes, we may
need to bump the packages depending on it. But with three different db
implementations, this could be overlooked.

Another problem is that we could have two of the same packages depending
on some db that have identical package version numbering -- but are not
the same package (since have different dependencies and possibly due to
detected db may have different features).

I'd like to suggest that we pick a DB and stay with it.

Also, maybe some packages maybe should use the lightest weight db.

For example, on some of my boxes I have db4-4.2.52nb5 which is required
by:
        shadow-4.0.4.1
        openssh-3.9.1nb1
        xorg-clients-6.8.1nb3
        PAM-0.77nb2
        openldap-2.2.13nb3

(And on another box, it is required by man-db-2.4.2,
evolution-data-server-0.0.90, apr-0.9.5.2.0.49, PAM-0.77nb2, and
openldap-2.2.13nb3.)

Plus, my pkg* tools are using the db4 installed libraries.

I also have db-2.7.7nb1 required by: py23pth-mxDateTime-2.0.5
and py23pth-sqlite-0.5.0. (On another box, python23-pth-2.3.3nb2.)

And on same box, db3-3.11.2nb1 required by nothing. (On another box,
required by evolution-1.4.6.)

I think the goal was to not have to pick a db so you would have to have
multiple installed. But that problem still exists (at least for me).

Any ideas on how this can be improved?

One idea would be to phase out db3 (except for rare package that requires
it). Use db2 for everything needing a light-weight db (if that is true
that db2 is quicker and/or smaller). And then use db4 for rest.

 Jeremy C. Reed

 	  	 	 technical support & remote administration
	  	 	 http://www.pugetsoundtechnology.com/