[RFC PATCH] Mock multi-config build patch -- implement multi-config

[seth vidal]

On Wed, 2006-05-10 at 17:04 -0500, Michael_E_Brown at 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 at redhat.com
>         [mailto:fedora-buildsys-list-bounces at redhat.com] On Behalf Of
>         Michael_E_Brown at Dell.com
>         Sent: Wednesday, May 10, 2006 4:21 PM
>         To: fedora-buildsys-list at 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