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

Alexander 'Leo' Bergolth leo at strike.wu-wien.ac.at
Thu Jan 29 11:27:42 UTC 2009

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

So I think it would be useful if RPM provided this information to the
scriptlets via environment variables. All calls to rpm could be
eliminated from the scriptlets this way.

e-mail   ::: Leo.Bergolth (at) wu-wien.ac.at
fax      ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

More information about the Rpm-list mailing list