mock rpmdb version issue with epel-5-i386 target

[Alan Franzoni]

2009/9/14 Mike McLean <mikem at redhat.com>:
> 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.

Yes, I had noticed that.

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

Sure it is, and such activity is not performed inside any of any SPEC.

 I think that maybe I just asked the wrong question.

One of my targets is to build SRPMs inside an epel-5-i386 chroot; this
can be done pretty easily with mock, but what if I have a dependency
on an RPM which is not available in a yum repo? I'd like to test some
internally built rpms in a pseudo-production environment *before*
they're sent to our repo. So I just wanted to use "--copyin", then use
--shell to manually invoke rpm and manually install such packages.
Also, sometimes some packages have build dependencies that can't be
satisfied by repos and should be installed manually (again, dependency
on a test package).

If it's the quickest path I'll just setup an internal, testing only,
can-be-trashed-at-any-time repository, possibly on the vary same
machine hosting mock.

Then I'll also need to build "full" images for some machines to deploy
(e.g. a gzipped tar which holds the full operating system along with
some rpms) in our testing environment, but I suppose I can use
cobbler/koan for that, and I imagine they work differently and support
a working rpm inside?




-- 
Alan Franzoni
--
contact me at public@[mysurname].eu