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
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.
One possibility, if you are only building for epel-5 and earlier, is to
use an older version of rpm on the host, perhaps just a stock epel-5
install. You'll be unable to build for Fedora 11+ on such a host, though.