Re: [RFC PATCH] Mock multi-config build patch -- implement multi-config
On Wed, 2006-05-10 at 17:04 -0500, Michael_E_Brown(a)Dell.com wrote:
And here is the multi-srpm, multi-config patch, built on top of the
previous two. The changes are relatively minor, just re-indenting the
last part of main(), no significant code changes except changing
options.chroot to an array and adding a loop.
Please let me know what you think.
--
Michael
______________________________________________________________
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Michael_E_Brown(a)Dell.com
Sent: Wednesday, May 10, 2006 4:21 PM
To: fedora-buildsys-list(a)redhat.com
Subject: [RFC PATCH] Mock multi-config build patch -- prepare
All,
Here is stage one of a patch series to implement
multi-config builds with mock. I believe this patch stands on
its own, so I am sending it separately. It is applied on top
of the earlier patch today to do multi-srpm builds.
The patch simply re-arranges main() by taking and
putting several sections into their own function. For example,
the clean and prep sections were very similar and have been
factored into their own function. The setting of defaults for
config_opts is moved into its own function.
The result is no functional change to the operation of
mock, but it makes the next patch in my series much easier,
which is the addition of multiple config builds, like this:
$ mock -r CFG1 -r CFG2 -r CFG3 -r CFG4 … srpm1 srpm2
srpm3 …
The next patch in the series will be a straightforward
patch to implement the above on top of this patch. The last
patch I would like to send would be to be able to run the
prep() sections for the different configs in parallel (simple,
via fork()) to reduce setup time.
why would this be valuable?
why not simply spawn off the jobs in multiple terminal windows or screen
sessions and not complicate the code with the forking and also confusing
the user as to what -r config -r config -r config does?
This would be adding A LOT of complexity to mock where it isn't
necessary and making the user case more difficult to know what you would
get. As an example does the above mean:
srpm1 will be built with cfg1
srpm2 will be built with cfg2
srpm3 will be build with cfg3
or does it mean
srpm1 will be built with configs 1, 2 and 3
srpm2 will be built with configs 1, 2 and 3
srpm3 will be built with configs 1, 2 and 3
let's not clutter up interfaces for some special case we're targeting.
-sv