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

[devzero2000]

On Tue, Jan 27, 2009 at 9:34 AM, Panu Matilainen
<pmatilai at laiskiainen.org>wrote:

> 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.


Excuse the delay in the response.

It seems that the problem has some point in common with the package bundle
and its alleged issues,  which  is recently, but also in the past, often
discussed.

Can you provide references to cases happened in the past, for example in the
last five years, that may have generated issues or reproducible examples
that can cause problems always?

Anyway the change to an incompatible behavior of  the NPTL futex glibc or
the upgrade to a incompatible RPM version occur in decades  AFAIK.

Thanks

(Aside)

if the reported bugzilla does not seem correct, you should close it with a
CLOSED WONTFIX.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rpm.org/pipermail/rpm-list/attachments/20090129/333e0764/attachment.htm