dist-upgrade: usage of rpm in pre-/postinstall scripts

[Panu Matilainen]

On Mon, 26 Jan 2009, devzero2000 wrote:

> On Sat, Jan 24, 2009 at 2:45 PM, Alexander 'Leo' Bergolth
> <leo at strike.wu-wien.ac.at> 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 -