Bug#367853: libdb transition policy?
On 30 May 2006, at 12:50, Gerfried Fuchs wrote: Hi! Sorry for late response. * "Nikita V. Youshchenko" <[EMAIL PROTECTED]> [2006-05-24 12:10]: However, contrary to what the NM templates suggest, symbol versioning is not a cure-all for all ABI incompatibilities. If libetpan returns a DB_ENV * in its API, you need to port[1] all its dependencies to the new Berkeley DB version. No, libetpan uses libdb only internally, and does not export it. So I guess the question is to people who maintain etpan-ng and sylpheed-claws-gtk2 - is it safe for your packages if I will upload new version of libetpan (without soname change or package name change) that will link against libdb4.4? I don't know if anyone has tried to, but I spoke to Hoa (= upstream) about the thing, and it was like I expected: libetpan uses libdb for its cache files. If it can't read them (like, b0rked file, or incompatible old db file) it would get regenerated anyway. So there is no compatibility problem with changing the libdb in libetpan at all. In fact, I checked the code and it does not this, the database won't be regenerated but that might be a enhancement to implement in libetpan. Do we need a release to fix this ? That means that cache files must be deleted by the user. -- DINH Viêt Hoà
Bug#367853: libdb transition policy?
> Have fun with updating the library, it won't affect depending packages. > :) Some times are that easy to solve, you know? Ok, will upload today :) pgpIuC2az1vuQ.pgp Description: PGP signature
Bug#367853: libdb transition policy?
Hi! Sorry for late response. * "Nikita V. Youshchenko" <[EMAIL PROTECTED]> [2006-05-24 12:10]: >> However, contrary to what the NM templates suggest, symbol versioning >> is not a cure-all for all ABI incompatibilities. If libetpan returns >> a DB_ENV * in its API, you need to port[1] all its dependencies to the >> new Berkeley DB version. > > No, libetpan uses libdb only internally, and does not export it. > > So I guess the question is to people who maintain etpan-ng and > sylpheed-claws-gtk2 - is it safe for your packages if I will upload new > version of libetpan (without soname change or package name change) that > will link against libdb4.4? I don't know if anyone has tried to, but I spoke to Hoa (= upstream) about the thing, and it was like I expected: libetpan uses libdb for its cache files. If it can't read them (like, b0rked file, or incompatible old db file) it would get regenerated anyway. So there is no compatibility problem with changing the libdb in libetpan at all. Have fun with updating the library, it won't affect depending packages. :) Some times are that easy to solve, you know? So long, Alfie -- So ist das Leben eben: Es muss Beben geben, ab und zu. Noch eben standst Du in der Sonne -- uuh, da kommt der Regen -- Seeed, "Tide Is High" signature.asc Description: Digital signature
Bug#367853: libdb transition policy?
On Wed, May 24, 2006 at 07:59:48AM +0200, Florian Weimer wrote: > > Why that? It would only affect packages that (correctly or wrongly) also > > depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have versioning, > > otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 are better in > > that regard.) > Berkeley DB 4.2 was compiled such that every exported symbol ends with > "_4002". Have a look at: > $ readelf -sW /usr/lib/libdb-4.2.so | grep -v _4002 > This means that even though it does not use symbol versioning, it can > coexist with other versions in the same process image. > However, contrary to what the NM templates suggest, symbol versioning > is not a cure-all for all ABI incompatibilities. If libetpan returns > a DB_ENV * in its API, you need to port[1] all its dependencies to the > new Berkeley DB version. Then again, if libetpan returns a DB_ENV * in its API, it deserves a special award for retarded library design. Happily, it doesn't do this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#367853: libdb transition policy?
> * Andreas Barth: > > Why that? It would only affect packages that (correctly or wrongly) > > also depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have > > versioning, otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 > > are better in that regard.) > > Berkeley DB 4.2 was compiled such that every exported symbol ends with > "_4002". Have a look at: > > $ readelf -sW /usr/lib/libdb-4.2.so | grep -v _4002 > > This means that even though it does not use symbol versioning, it can > coexist with other versions in the same process image. > > However, contrary to what the NM templates suggest, symbol versioning > is not a cure-all for all ABI incompatibilities. If libetpan returns > a DB_ENV * in its API, you need to port[1] all its dependencies to the > new Berkeley DB version. No, libetpan uses libdb only internally, and does not export it. So I guess the question is to people who maintain etpan-ng and sylpheed-claws-gtk2 - is it safe for your packages if I will upload new version of libetpan (without soname change or package name change) that will link against libdb4.4? Nikita -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367853: libdb transition policy?
* Andreas Barth: > Why that? It would only affect packages that (correctly or wrongly) also > depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have versioning, > otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 are better in > that regard.) Berkeley DB 4.2 was compiled such that every exported symbol ends with "_4002". Have a look at: $ readelf -sW /usr/lib/libdb-4.2.so | grep -v _4002 This means that even though it does not use symbol versioning, it can coexist with other versions in the same process image. However, contrary to what the NM templates suggest, symbol versioning is not a cure-all for all ABI incompatibilities. If libetpan returns a DB_ENV * in its API, you need to port[1] all its dependencies to the new Berkeley DB version. [1] A simple recompilation may not be enough because a new Berkeley DB version usually changes the API in slight ways. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367853: libdb transition policy? (Was: Re: Bug#367853: libetpan: Please consider transitioning to libdb4.4)
* Nikita V. Youshchenko ([EMAIL PROTECTED]) [060523 17:22]: > However, if I will build library against libdb4.4 instead of libdb4.2, this > will probably break any binaries built against the library - both packaged > and local. Why that? It would only affect packages that (correctly or wrongly) also depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have versioning, otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 are better in that regard.) AFAICS, this is only the case with etpan-ng. So, perhaps a conflict between your new version and the current version of etpan-ng and an upload of a changed version of etpan-ng (with a conflict to the current version of libetpan) could help? Gerfried, what do you think? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367853: libdb transition policy?
> * Nikita V. Youshchenko: > > However, if I will build library against libdb4.4 instead of > > libdb4.2, this will probably break any binaries built against the > > library - both packaged and local. > > What kind of interface does libetpan expose? Based on the package > description, I wouldn't expect the library to export any Berkeley DB > objects at all. Library internally uses libdb (to maintain mail cache, and probably for other things also), and is currently linked against libdb4.2. So the issue exists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367853: libdb transition policy?
* Nikita V. Youshchenko: >> * Nikita V. Youshchenko: >> > However, if I will build library against libdb4.4 instead of >> > libdb4.2, this will probably break any binaries built against the >> > library - both packaged and local. >> >> What kind of interface does libetpan expose? Based on the package >> description, I wouldn't expect the library to export any Berkeley DB >> objects at all. > > Library internally uses libdb (to maintain mail cache, and probably > for other things also), and is currently linked against libdb4.2. So > the issue exists. Berkeley DB uses symbol versioning, so I don't think changing the DB version will affect the library ABI. You need to devise a procedure for upgrading the database environments, of course. But this is completely separate from soname issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367853: libdb transition policy?
* Nikita V. Youshchenko: > However, if I will build library against libdb4.4 instead of > libdb4.2, this will probably break any binaries built against the > library - both packaged and local. What kind of interface does libetpan expose? Based on the package description, I wouldn't expect the library to export any Berkeley DB objects at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367853: libdb transition policy? (Was: Re: Bug#367853: libetpan: Please consider transitioning to libdb4.4)
[CCing to -devel and to people who maintain packages that depend on libetpan] > Package: libetpan > Severity: wishlist > > > Hi, > currently several versions of the berkeley db libraries are used in the > archive: libdb[4.2,4.3,4.4]. > Please consider upgrading to libdb4.4 in order to ship etch with fewer > versions of this library. Thank you for pointing this. However, if I will build library against libdb4.4 instead of libdb4.2, this will probably break any binaries built against the library - both packaged and local. Asking upstream to change soname is IMO not an option in this case because libdb transition is debian internal activity, and upstream has nothing to do with it. So how to handle this? Change soname (making it different from upstream)? Reading Library Packaging guide [1] could not point me to any particular solution. Btw, I guess the same situation is with other packages also - maybe there is some policy around this particular transition? Nikita [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
