mock rpmdb version issue with epel-5-i386 target

Panu Matilainen pmatilai at laiskiainen.org
Wed Sep 16 07:40:35 UTC 2009


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 
> use.
>
> 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 
so far.

 	- Panu -




More information about the Fedora-buildsys-list mailing list