On Mon, 2008-07-28 at 21:39 -0400, Tom Lane wrote: > Jesse Keating <jkeating@xxxxxxxxxx> writes: > > It's actually having problems with one of your %patch arguments. The > > srpm is initially created on a RHEL5 system, before passed to mock, so > > perhaps rpm on RHEL5 doesn't accept the -F flag... that is the recent > > thing you changed right? > > Doh, that must be it. Thanks for the clue. > > (Is it really a good idea to be using a back-rev rpm for one part of > the build process, and the latest and greatest for other parts? It > certainly calls future build reproducibility into question, if you ask > me.) I have suggested - multiple times - that for mock the only thing the system's rpm should be used for is generating the chroot, and that after doing that (and chrooting inside and rebuilding the rpmdb) all further use of rpm would be from inside the chroot. There is a minor issue in doing so, which is that you'd either need to teach yum about how to run in a chroot, or you'd need to modify mock to get packages into the buildroot before running (the chroot's) yum on them. The reason is that if you don't, then the chroot's yum needs access to the network, which is generally taken to be a bad idea. The other problem with this is the construction of the SRPM itself, which should also be done with the rpm that's expected to build it. Again, we could do this by constructing a chroot containing rpm and the scm tool of choice for checkout, and at least in principle that bit of network access is no more problematic than what we're already doing. The patch, I'm sure, would be gratefully accepted. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
