On Mon, 26 Jan 2009, devzero2000 wrote: > On Sat, Jan 24, 2009 at 2:45 PM, Alexander 'Leo' Bergolth > <leo@xxxxxxxxxxxxxxxxxxxx> wrote: > Hi! > > When upgrading to Fedora 10, the newer Berkeley-DB version > used in F10 > causes the following error messages after RPM itself has been > upgraded: > > -------------------- 8< -------------------- > rpmdb: Program version 4.5 doesn't match environment version > 0.128 > error: db4 error(-30972) from dbenv->open: > DB_VERSION_MISMATCH: Database > environment version mismatch > error: cannot open Packages index using db3 - (-30972) > error: cannot open Packages database in /var/lib/rpm > -------------------- 8< -------------------- > > This is because some environment files (__db.00*) of the > rpm-database > remain from the previous version. To work around this error, > rpm has a > posttrans scriptlet that deletes those environment files: > > -------------------- 8< -------------------- > posttrans scriptlet (using /bin/sh): > # XXX this is klunky and ugly, rpm itself should handle this > dbstat=/usr/bin/db45_stat > if [ -x "$dbstat" ]; then > if "$dbstat" -e -h /var/lib/rpm 2>&1 | grep -q "doesn't > match > environment version \| Invalid argument"; then > rm -f /var/lib/rpm/__db.* > fi > fi > exit 0 > -------------------- 8< -------------------- > > However, this scriptlet is called after the rpm transaction > has > finished, so any other rpm that follows the rpm-upgrade in > the same > transaction and that calls rpm inside one of its scriptlets > will produce > the error and the corresponding script will fail. > > When doing a dist-upgrade, even when only upgrading rpm as a > first step, > the packages needed to satisfy the dependencies will cause > the above > error. (E.g. openldap-servers contains a call to "rpm -q" in > order to > check if the ldap-database needs to be migrated.) > > Is there any workaround for this problem? > > > IMHO, should be useful to patch RPM 4.6 (././lib/backend/db3.c db_init) > for resolving this - old - issue. For RPM 4.4.2.x.x.x the patch is > > https://bugzilla.redhat.com/show_bug.cgi?id=464752 > > > (not applied anyway in 4.4.2.3-9.el5). Not hard to do in RPM 4.6 also. > Sorry if isn't the workround you have asked. Blindly blasting away the environment that provides the means for safe concurrent access (including protects the db from being accessed with incompatible DB version, ie the error message above) to the rpmdb when it happens to prevent access is not a solution at all IMO. When the underlying BDB gets upgraded, you have two versions of rpm, linked against different, potentially incompatible versions of BDB, accessing the rpmdb concurrently with all protection removed. Not good. The only thing that can safely and reliably access the rpmdb across DB version upgrades, glibc futex implementation changes and the like, is the single process performing the transaction. This also means there's precisely one way scriptlets could reliably access the rpmdb, and that's the embedded Lua interpreter. As of 4.4.2.x and 4.6.0 the embedded Lua interpreter doesn't have access to rpmdb but there's work going on to change that. But no, there's no good workaround at the moment. - Panu - _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
