On Mon, 14 Sep 2009, Mike McLean wrote:
On 09/14/2009 11:50 AM, Alan Franzoni (mailing) wrote:
> It seems the rpmdb of the chroot has been created with an rpm
> employing a different format ( I can assume it's the 'host' system rpm
> ), hence leading to a format mismatch which prevents from using rpmdb
> from inside the chroot.
> I have tinkered around for a little, but I couldn't find an easy
> solution (beyond installing everything from outside using mock
> --install, of course). Hence I've got some questions:
The chroot is created from outside the chroot, and hence uses that version of
rpm. Consider that when the process starts, there is no rpm in the chroot to
Note that mock does make it easy to install things manually in the chroot
from the outside.
> Is that an intended behaviour?
intended may be reaching, but known, expected, unavoidable -- yes
> Is the rpmdb supposed to be converted
> back to the proper format later on in the deployment process, if using
> mock for building packages which be used later on in a possibly
> pre-build system?
There is no back conversion. I'm not sure how this should affect any
deployment process for the resulting builds. The rpmdb in the chroot should
generally not be accessed by the build itself. Any such activity in a spec
file is unwise and questionable.
It is unfortunate that this incompatibility was introduced in rpm, but it was
for a good reason -- sha256 sums replaced semi-insecure md5sums.
Mind you, the error here has nothing to do with sha256/md5:
rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9
error: cannot open Packages index using db3 - Invalid argument (22)
error: cannot open Packages database in /var/lib/rpm
This is a much lower level thing, a Berkeley DB internal format
incompatibility: BDB can always read (up to a point) databases created
with older versions, but there's no guarantee the other way around. For
example BDB 4.3 and 4.5 were interchangably compatible but BDB 4.7 (which
is what RPM in Fedora 11 uses) is not.
The rpm-level view of the database hasn't really changed since the very
beginning - it's just a pile of header binary blobs and some associated
indexes. It is in fact possible to manually downgrade the database to and
older BDB format by using db_dump and db_load of appropriate BDB versions,
it's just not something that can be automatically done by RPM. So while
not exactly practical, you can install say RHEL 5 package set with Fedora
11 RPM, manually downgrade the BDB format to RHEL 5 RPM's level with BDB
tools, do rpm --rebuilddb with the RHEL 5 rpm to recreate indexes and
voila, you have fully "converted the db for later deployment".
And then there's the third level of compatibility: the data contained
within headers and it's interpretation. The md5 vs sha256 (or actually,
the algorithm is configurable) is just interpretation of tag values, the
data types of these are recognizable and accessible by pretty much any old
RPM you can dig up, but those older rpm versions wouldn't know what to do
with this tag even though they can load such a header. A more fundamental
issue is header data types unknown to older versions: RPM 4.6 introduced
64bit integer type, and headers containing such data cannot be even loaded
by older RPM versions as internal consistency checks cause failure on
unknown data types. Because this is such a grave incompatibility, RPM
avoids using 64bit types in headers when they're strictly not needed, ie
if 32bit integer is sufficient to contain the package/file sizes. To my
knowledge, there are no > 4GB packages in Fedora so this is not an issue
- Panu -