Re: [gentoo-dev] Berkeley DB, coexistence of different versions

[Paul de Vrieze]

On Tuesday 13 September 2005 04:23, Robin H. Johnson wrote:
> On Tue, Sep 13, 2005 at 12:50:47AM +0200, Stefaan wrote:
> > Hi all!!
> >
> > Here's an issue Seemant and I have been struggling with, and doesn't
> > seem as easy to solve as like touching one ebuild.
>
> You're making the problem seem much larger than it is.
>
> Pauldv and myself have been managing berkdb pretty well, I haven't seen
> bugs on it in a long time.
>
> > Berkeley DB comes in many flavors.  Judging by the slots in the
> > ebuilds (1, 3, 4, 4.1, 4.2, 4.3) there's many different interface
> > versions.  This comes with the added fun of having packages depend on
> > certain versions of DB.  Nothing shocking so far.
> >
> > However, looking at the heimdal-package we noticed several problems
> > (which seem to be more widespread than just heimdal):
>
> [snip]
>
> Fix your package to compile with any version of db, that's the general
> approach that has been taken so far, and it's been largely successful.
>
> You should use these libraries and headers:
> /usr/lib/libdb.{so,a}
> /usr/include/db.h
>
> If you want to limit it to a certain reason of DB for some other
> reason, then consider /usr/include/db1, /usr/include/db3,
> /usr/include/db4, /usr/include/db4.X.
>
> And use the unversioned functions (db_create instead of
> db_create_4002). To deal with the varying number of arguments, have a
> look at
> PHP/nss_ldap - the fix is pretty simple, just an extra argument if the
> version is 4 or newer (IIRC, but check).
>
> Detection of some specific version is bad! Just figure out what major
> version, and do the correct thing for that series.
>
> In a bunch of cases, the best approach has been to just rip out
> upstreams stuff from configure.in, and write it properly, and submit it
> back to them (definetly see PHP4 in this regard).
>
> Also take a look at db4-fix.eclass.
>
> You claim the interface versions have changed, but the code is still
> largely compatible. What's a larger issue is the fact that you can
> upgrade an existing database, but not downgrade it.
>
> If you are stuck updating the package for this, then give me or pauldv
> a shout.

The major issue with berkeley db is only that we build using "versioned 
symbols", a setup that prevents header/lib mismatches and allows 
different library versions to coexist in one binary (a situation that 
unfortunately happens with db as it's not strong on binary compatibility. 
Version 4.3 however does not offer this symbols anymore, which is the 
main reason it is masked. If you want to do some nice work you could work 
on using linking scripts to do versioning properly (and use the ELF 
versioning system). That leaves the poor detection of db packages by 
other packages/configure scripts. Unfortunately many configure scripts 
are just broken. The proper name of a library name according to the 
standards for library names is db-4.2.so, db-4.so and db.so to exist for 
all versions. A package should try to look for the most appropriate one 
of those, but many configure scripts look for redhat-isms like "db4.so". 

The db.eclass maintains shared info by all db3 and db4 versions such that 
/usr/include/db.h and /usr/lib/db.so allways point to the most recent 
version of db installed.

On the configure scripts, the best approach is to have a test program that 
includes the db header and then checks whether the header and library 
versions are equal. The problem with checks for db_create is that this 
function is called db_create4002 for db4.2 and this mapping is provided 
in the header file. If the header file is not included in the test 
program, the test fails.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net