[Python-Dev] Distutils confuses Berkeley DB and dbm?

[Barry A. Warsaw]

>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:

    SM> The bsddb build problem is essentially that some (many? most? 
    SM> all?) Linux distributions ship with multiple versions of the
    SM> Berkeley DB library now.  To make matters worse, they separate
    SM> the shared libraries (in base rpms) from the include files (in
    SM> -devel rpms).  On my Mandrake system that gives you six
    SM> possible rpms to install: dbX and dbX-devel, for X in {1,2,3}.
    SM> Based on the way distutils checks for libraries and include
    SM> files (which I believe is mostly my fault), if you have only
    SM> one of any given pair of such rpms, like Barry, you might wind
    SM> up compiling with one version of the library and trying to
    SM> link with a different version.

It's worse than that.  On my MD8.2 system, I've got at least 4
versions of Berkeley installed:

    db1-1.85-7mdk + db1-devel-1.85-7mdk
    db2-2.4.14-5mdk + db2-devel-2.4.14-5mdk
    libdb3.3-3.3.11-7mdk + libdb3.3-devel-3.3.11-7mdk

Those are all installed with a fairly beefy package selection, but
nonetheless stock packages.  Then I've got Berkeley DB 3.3.11
installed from source sitting in its default installation spot of
/usr/local/BerkeleyDB.3.3 and 4.0.14 sitting in
/usr/local/BerkeleyDB.4.0 ... sigh!

I wouldn't argue if you said it was a mess. ;)  So what do we do?

I still think that pybsddb is a worthy candidate for inclusion in the
standard library and it should link against 3.3.11 out of the box.  I
believe the cvs snapshot of pybsddb links against 4.0.14 as well.

Then there's this bug

http://sourceforge.net/tracker/index.php?func=detail&aid=408271&group_id=5470&atid=105470

Maybe we should lock bsddbmodule down to Berkeley 1.85 and then pull
pybsddb (which exports as module bsddb3) for Berkeley 3.3.11.  If
there's a clamor for it, I suppose we could fake a bsddb2 and bsddb4
for those major versions of Berkeley.

-Barry