version-independence between Python & BerkDB in Solaris packages?

[Skip Montanaro]

This is kinda off-topic for this group, but since I'm packaging Python
perhaps not too far OT.

I built a Solaris package for Python 2.3.3 then copied it to another system
and installed it. Nothing too earth-shaking there. When I ran the
regression test it barfed in test_bsddb because it couldn't find the
Berkeley DB library. I went back to the first system and am now in the
midst of updating from DB 4.0.14 to DB 4.2.52 and will then build a Solaris
package for it.

Unfortunately that means I'll have to rebuild and repackage Python as well,
since _bsddb.so depends on a specific Berkeley DB package:

% ldd _bsddb.so
libdb-4.0.so => /usr/local/BerkeleyDB.4.0/lib/libdb-4.0.so
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1

Is it possible to compile and package Python and the external libraries it
uses to minimize coupling between package versions like this? I note that
other modules which link to specific external libraries don't have such
problems:

% ldd zlib.so
libz.so => /usr/lib/libz.so
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1

Maybe it's just unavoidable with Berkeley DB because there are so many
versions liable to be installed simultaneously.

Thanks,

Skip

[Martin v. Loewis]

Skip Montanaro wrote:

Is it possible to compile and package Python and the external libraries it
uses to minimize coupling between package versions like this?
There are several alternatives:

1. Link _bsddb.so statically with a libdb.a. Then you don't need
any additional shared libraries on the target system. You may find
that _bsddb.so can't open databases of the "system's" libdb-x.y.so,
though.

2. Be prepared to have multiple versions of libdb installed on a system.
BerkeleyDB is deliberately packaged in a way to make this possible:
You can have /usr/local/BerkeleyDB-4.0, and, at on the same system,
/usr/local/BerkeleyDB-4.2. Still the same problem as in 1) with
opening newer databases.

3. Package _bsddb.so separately from Python. This is the typical
Linux answer. Then provide multiple copies of _bsddb.so, each
packaged for its own libdb-x.y. The different packages should
conflict with each other. Can be combined with either 1 or 2.
I note that
other modules which link to specific external libraries don't have such
problems:

% ldd zlib.so
libz.so => /usr/lib/libz.so
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1

That's because libz.so is part of the operating system. Even if
newer libz releases are available, nobody would install them
on Solaris (anymore), since it is so convenient to use the
system library. If Sun ever decides to bundle Sleepycat with
the system, the same thing may happen: Solaris 11 comes with
BerkeleyDB 4.7.178, and nobody installs 4.9.26 even though this
has been available for three months already. Instead, people
upgrade to Solaris 12 when it comes out.

Regards,
Martin