[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 26 Jan 2015 06:51:09 +0300
From: "(GalaxyMaster)" <galaxy@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: removing /var/lib/rpm/__db.00? on rpm upgrade (was: recent updates)
Solar,
On Thu, Jan 15, 2015 at 01:31:43PM +0300, Solar Designer wrote:
> BTW, we (you?) should probably introduce a trigger into rpm.spec, so
> that /var/lib/rpm/__db.00? are automatically removed on upgrades from
> our older versions of rpm known to have these in incompatible format.
Well, I agree with the approach, however there is another thing we may
want to consider. There are two types of the databases the new RPM
supports: hash and btree. The legacy one is the hash database and it's
believed to be slower. The behaviour you've described could be seen
when the database was upgraded from hash to btree and there are old DB
environment hanging around. I don't know how the following has happened
on jill, but I suspect that this was the reason for the segmentation
faults:
===
galaxy@...l:~/nobackup $ file /var/lib/rpm/*
/var/lib/rpm/Basenames: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Conflictname: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Dirnames: Berkeley DB (Btree, version 9, native byte-order)
/var/lib/rpm/Filemd5s: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Group: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Installtid: Berkeley DB (Btree, version 9, native byte-order)
/var/lib/rpm/Name: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Packages: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Providename: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Provideversion: Berkeley DB (Btree, version 9, native byte-order)
/var/lib/rpm/Pubkeys: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Requirename: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Requireversion: Berkeley DB (Btree, version 9, native byte-order)
/var/lib/rpm/Sha1header: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Sigmd5: Berkeley DB (Hash, version 8, native byte-order)
/var/lib/rpm/Triggername: Berkeley DB (Hash, version 8, native byte-order)
===
What we may want to do during the installation of the updated RPM package is to
upgrade the whole database to btree.
Or we just may replace the current trigger you mentioned with a simple one that
remove the environment files during the upgrade of the package. As it was
mentioned in the comment, the RPM process doing the upgrade has all these
environment files already open, so it won't be hurt by removing them, and the
very next invocation of the new RPM will re-create the files properly. This is
the easiest option (implementation-wise), but we will get mixed databases
types/versions in the RPM database (depending on the RPM version we are
upgrading from).
--
(GM)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
