On Monday 14 September 2009 01:09:26 pm Alan Franzoni wrote:
2009/9/14 Mike McLean <mikem(a)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).
build your srpm with --nodeps that way you dont need the
buildrequires
packages installed to make your srpm. this is how koji does it.
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.
setup a local repo. is the easiest way.
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?