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

devzero2000 pinto.elia at gmail.com
Thu Jan 29 12:16:29 UTC 2009


On Thu, Jan 29, 2009 at 12:27 PM, Alexander 'Leo' Bergolth <
leo at strike.wu-wien.ac.at> wrote:

> On 01/27/2009 09:34 AM, Panu Matilainen 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:
> >>       -------------------- 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:
> [...]
> >>       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.
>
> The purpose of all calls to rpm I found inside pre or post scriptlets is
> to obtain the version of the currently installed package or the upgrade.
>

Not the only. For example there are commercial packages that have no correct
dependencies or incorrect pre/post install. Or commercial packages that
require an interactive EULA. Or if you want to make a yum-pull-update -  do
a search if interested- without using special agent - a yum-pull-update is
equivalent to to a package bundle.
Anyway for  quering package , more that env var, could be useful to use the
internal lua interpreter and the rpm lua extension.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rpm.org/pipermail/rpm-list/attachments/20090129/7804c563/attachment.htm 


More information about the Rpm-list mailing list