Hi, I just did an revdev-rebuild because of the libcom_err.so.2|3 problem and ran into trouble with subversion: * subversion-1.1.3 was rebuild * but now using "db-4.2.52_p2" (marked x86-stable on 2005/05/29) instead of "db-4.1*" This results in an bdb-error Program version 4.2 doesn't match environment version when accessing repos that were created using "db-4.1". At the moment I'm downgrading to "db-4.1" * mask and unmerge db-4.2* * revdep-rebuild After this I'm migrating the (remaining) bdb-4.1-repos to "fsfs" to get rid of bdb-problems entirely. Cheers, Axel
Maybe a better workaround than the one that I've chosen: http://svn.haxx.se/users/archive-2005-07/0827.shtml Axel
It "should" work (but doesn't). The "solution" would be to first dump the database and then reload it after the upgrade of bdb. One of the problems with bdb.
This is actually what I have done (it worked), with the difference that I've chosen (now) "fsfs" for the target repository's fs-type . Axel
As a "resolution" for this "bug" I would like to recommend two warning messages similar to "com_err" 1. RapidSVN: Updating to a newer version of "sys-libs/db" might break an existing subversion installation, i. e. you might no longer be able to access bdb-repositories that were created using a previous version of "sys-libs/db". We therefore recommend to use/switch to fs-type "fsfs" for all your repositories. 2. db: -- the same --
Sorry, I meant "subversion" not "Rapdsvn"... ... and there already is a warning message, but it is a little bit "outdated", i. e. one doesn't deduce that updating from "db-4.1" to "db-4.2" would cause problems. Axel
berkeley db is a horible beast to manage properly. Basically any update in db version used except for the final digit requires the repository to be rebuild. This means that you must first dump the repos with the old version, merge the new apr/apu|apache and subversion and then reload the repos. This is one of the reasons that fsfs is now the default format.
I think there's nothing more that we can do here. I've added a note to the gentoo portage browser, too. Users that get into trouble, because they still use the bdb backend, will either find the "portage note" or this bug report, when searching with "ALL". Resolving the bug with resolutionn "CANTFIX" seems reasonable, because it's not something that can be solved by a gentoo ebuild. Axel
