From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EFYJ0-0003h5-CP for garchives@archives.gentoo.org; Wed, 14 Sep 2005 14:32:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j8EEQHrU007673; Wed, 14 Sep 2005 14:26:17 GMT Received: from callisto.cs.kun.nl (callisto.cs.kun.nl [131.174.33.75]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j8EEOQfQ012325 for ; Wed, 14 Sep 2005 14:24:26 GMT Received: from localhost (localhost [127.0.0.1]) by callisto.cs.kun.nl (Postfix) with ESMTP id C60A52E80BD for ; Wed, 14 Sep 2005 16:29:03 +0200 (CEST) From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Berkeley DB, coexistence of different versions Date: Wed, 14 Sep 2005 16:28:53 +0200 User-Agent: KMail/1.8.2 References: <28edf05e05091215505f3d41aa@mail.gmail.com> <20050913022300.GB14440@curie-int.orbis-terrarum.net> In-Reply-To: <20050913022300.GB14440@curie-int.orbis-terrarum.net> X-Face: #Lb+'V@sGJ;ptgo5}V"W+5OCoo{LZv;bh,s,`WKLi/J)ed1_$0;6X<=?utf-8?q?700LVV/=3BLqPhiDP=5E=0A=09=27f=5Dfnv?=@%6M8\'HR1t=aFx;ePfp{ZQoBe+e)JOQ8T5*(_;mHY+cltLGq<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2224092.Naukqp5KMo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509141629.01746.pauldv@gentoo.org> X-Archives-Salt: ede637a8-a411-4faa-937e-f554ce31c431 X-Archives-Hash: 97a125144b5538fdab6f843bafb7368c --nextPart2224092.Naukqp5KMo Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 symbols", a setup that prevents header/lib mismatches and allows=20 different library versions to coexist in one binary (a situation that=20 unfortunately happens with db as it's not strong on binary compatibility.=20 Version 4.3 however does not offer this symbols anymore, which is the=20 main reason it is masked. If you want to do some nice work you could work=20 on using linking scripts to do versioning properly (and use the ELF=20 versioning system). That leaves the poor detection of db packages by=20 other packages/configure scripts. Unfortunately many configure scripts=20 are just broken. The proper name of a library name according to the=20 standards for library names is db-4.2.so, db-4.so and db.so to exist for=20 all versions. A package should try to look for the most appropriate one=20 of those, but many configure scripts look for redhat-isms like "db4.so".=20 The db.eclass maintains shared info by all db3 and db4 versions such that=20 /usr/include/db.h and /usr/lib/db.so allways point to the most recent=20 version of db installed. On the configure scripts, the best approach is to have a test program that= =20 includes the db header and then checks whether the header and library=20 versions are equal. The problem with checks for db_create is that this=20 function is called db_create4002 for db4.2 and this mapping is provided=20 in the header file. If the header file is not included in the test=20 program, the test fails. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart2224092.Naukqp5KMo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDKDOtbKx5DBjWFdsRAj4UAKDVBejdwyxALRTAr3IQITBPKsvpwgCfVuxn 2uQY50vTHvVmd2D1k3MJnRQ= =fCd5 -----END PGP SIGNATURE----- --nextPart2224092.Naukqp5KMo-- -- gentoo-dev@gentoo.org mailing list