version-independence between Python & BerkDB in Solaris packages?

[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