Here is a patch for review. I have made the "obvious" changes in order to be able to do the following: mock -r CFG srpm1 srpm2 srpm3 srpm4
Limitations: - There are no checks for dependencies between the srpms, so they should be independent. (no re-ordering of SRPMS) - Building one SRPM can leave the buildroot in an inconsistent state for the next SRPM. (no clean of chroot between builds) - Failure to build one SRPM stops the whole process. - Resulting RPMs are not installed into the build environment for use by subsequent SRPMS.
Reasoning: One problem I have been having with mock is speed. We are using mock to build for 16 distinct configurations. Doing prep on each configuration was taking a minute and a half to two minutes. As an optimization, our mock wrapper script was doing a single prep per chroot and then using --no-clean, but this complicates our wrapper script. I am building a set of related RPMS, so I don have much concern about cross-pollution. This simple patch simplifies my wrapper script considerably.
Future: One future direction I'd like to take this is a parallel mock that can prep/build multiple configurations at the same time to try to amortize the cost of prep stage by running prep of one environment in parallel with build of a different configuration. Currently, it is taking me an hour to build 16 sets of RPMS (5 SRPMS per set), and I am hoping to get this down. We have already implemented squid and some other measures to try to speed things up. -- Michael
<<mock-multi.patch>>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael_E_Brown@Dell.com wrote:
[RFC, PATCH] Build multiple srpms
Here is a patch for review. I have made the "obvious" changes in order to be able to do the following: mock -r CFG srpm1 srpm2 srpm3 srpm4
I like the patch. It doesn't change the currently expected behavior with one srpm, just adds the ability to build multiple srpms from one chroot.
Have you tried it with plague? If not, I'll put your version on my local plague server and see if it causes any grief (don't expect it to).
Limitations:
- There are no checks for dependencies between the srpms, so they
should be independent. (no re-ordering of SRPMS)
- Building one SRPM can leave the buildroot in an inconsistent state
for the next SRPM. (no clean of chroot between builds)
I don't have a problem with this. I'm not sure I buy the argument that we need to do a clean of the chroot every time. Partially that's because I do a lot of cross-tools stuff which requires that I keep a chroot around for multiple builds. But even discounting that, I don't see what building an srpm in a chroot can do that will corrupt the chroot so that a subsequent build will fail or be incorrect. Mostly you're in there because you want a particular set of binaries (programs and libraries). Once those are installed, who cares if the rpm database gets trashed or the passwd file has some crufty entries in it?
- Failure to build one SRPM stops the whole process.
I'm not sure that I would consider the "failure stops everything" a limitation, since it saves you having to dig through tons of log file entries to find where the failure occurred (I never liked that make option anyway :)). You could probably get away with removing the sys.exit() in the for loop, but then you'd have to remember the exit status, etc.
- Resulting RPMs are not installed into the build environment for
use by subsequent SRPMS.
Reasoning: One problem I have been having with mock is speed. We are using mock to build for 16 distinct configurations. Doing prep on each configuration was taking a minute and a half to two minutes. As an optimization, our mock wrapper script was doing a single prep per chroot and then using --no-clean, but this complicates our wrapper script. I am building a set of related RPMS, so I don have much concern about cross-pollution. This simple patch simplifies my wrapper script considerably.
What sort of speed improvement are you seeing now?
Future: One future direction I'd like to take this is a parallel mock that can prep/build multiple configurations at the same time to try to amortize the cost of prep stage by running prep of one environment in parallel with build of a different configuration. Currently, it is taking me an hour to build 16 sets of RPMS (5 SRPMS per set), and I am hoping to get this down. We have already implemented squid and some other measures to try to speed things up.
You could probably achieve the same result by using plague and invoking multiple plague-client builds from your wrapper script. You wouldn't be able to "pipeline" the builds (i.e. wait for build1 to reach build state, then start build2), but this will be simpler. Certainly simpler than threading mock.
Clark
On Wed, 2006-05-10 at 15:59 -0500, Clark Williams wrote:
I don't have a problem with this. I'm not sure I buy the argument that we need to do a clean of the chroot every time. Partially that's because I do a lot of cross-tools stuff which requires that I keep a chroot around for multiple builds. But even discounting that, I don't see what building an srpm in a chroot can do that will corrupt the chroot so that a subsequent build will fail or be incorrect. Mostly you're in there because you want a particular set of binaries (programs and libraries). Once those are installed, who cares if the rpm database gets trashed or the passwd file has some crufty entries in it?
The clean is non-negotiable. Pollution of chroot is a big deal, especially in wanting to make sure we've created consistent and repeatable builds, not to mention security.
As I mentioned to matt, Jochen, from several months ago, wrote a patch to do manual creation of a cached chroot so we could simply copy that image into place if it exists and run a 'yum update' on it to make sure it is current.
The clean is important for consistent builds and we must always have a clean chroot for our builds of fedora. Moving away from that requirement in mock (w/o special options) is just setting up users for confusion and failure.
I'm not sure that I would consider the "failure stops everything" a limitation, since it saves you having to dig through tons of log file entries to find where the failure occurred (I never liked that make option anyway :)). You could probably get away with removing the sys.exit() in the for loop, but then you'd have to remember the exit status, etc.
failure should stop everything, especially for related but not _Required_ builds happening before.
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
On Wed, 2006-05-10 at 15:59 -0500, Clark Williams wrote:
I don't have a problem with this. I'm not sure I buy the argument that we need to do a clean of the chroot every time. Partially that's because I do a lot of cross-tools stuff which requires that I keep a chroot around for multiple builds. But even discounting that, I don't see what building an srpm in a chroot can do that will corrupt the chroot so that a subsequent build will fail or be incorrect. Mostly you're in there because you want a particular set of binaries (programs and libraries). Once those are installed, who cares if the rpm database gets trashed or the passwd file has some crufty entries in it?
The clean is non-negotiable. Pollution of chroot is a big deal, especially in wanting to make sure we've created consistent and repeatable builds, not to mention security.
As I mentioned to matt, Jochen, from several months ago, wrote a patch to do manual creation of a cached chroot so we could simply copy that image into place if it exists and run a 'yum update' on it to make sure it is current.
I remember seeing it in the archives. Do you think we should look at merging that patch into the current yum?
The clean is important for consistent builds and we must always have a clean chroot for our builds of fedora. Moving away from that requirement in mock (w/o special options) is just setting up users for confusion and failure.
I'm not opposed to clean being the default; I understand the paranoia :).
My situation is a bit strange, since I use mock to maintain a "host" environment that contains a "sysroot". The sysroot is a set of target libraries and headers files that are used to generate packages for a non-x86 Linux system. So, I have an environment that gets built up over time as packages state their requirements. Since a clean of the chroot would blow away my sysroot, I don't want that to happen and go to great pains to insure that all the config files default 'clean' to false and all command lines have --no-clean. I suppose I could copy the sysroot out after the build and back in before a new build, but that just seems hokey...
I'm not sure that I would consider the "failure stops everything" a limitation, since it saves you having to dig through tons of log file entries to find where the failure occurred (I never liked that make option anyway :)). You could probably get away with removing the sys.exit() in the for loop, but then you'd have to remember the exit status, etc.
failure should stop everything, especially for related but not _Required_ builds happening before.
Hey, I build with -Werror!
Clark
On Thu, 2006-05-11 at 09:36 -0500, Clark Williams wrote:
As I mentioned to matt, Jochen, from several months ago, wrote a patch to do manual creation of a cached chroot so we could simply copy that image into place if it exists and run a 'yum update' on it to make sure it is current.
I remember seeing it in the archives. Do you think we should look at merging that patch into the current yum?
into yum? it doesn't need to go into yum. The feature need only be added to mock.
My situation is a bit strange, since I use mock to maintain a "host" environment that contains a "sysroot". The sysroot is a set of target libraries and headers files that are used to generate packages for a non-x86 Linux system. So, I have an environment that gets built up over time as packages state their requirements. Since a clean of the chroot would blow away my sysroot, I don't want that to happen and go to great pains to insure that all the config files default 'clean' to false and all command lines have --no-clean. I suppose I could copy the sysroot out after the build and back in before a new build, but that just seems hokey...
so is there something WRONG with --no-clean? Does that not meet your requirements?
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
On Thu, 2006-05-11 at 09:36 -0500, Clark Williams wrote:
As I mentioned to matt, Jochen, from several months ago, wrote a patch to do manual creation of a cached chroot so we could simply copy that image into place if it exists and run a 'yum update' on it to make sure it is current.
I remember seeing it in the archives. Do you think we should look at merging that patch into the current yum?
into yum? it doesn't need to go into yum. The feature need only be added to mock.
Gah. I meant mock, sorry...
My situation is a bit strange, since I use mock to maintain a "host" environment that contains a "sysroot". The sysroot is a set of target libraries and headers files that are used to generate packages for a non-x86 Linux system. So, I have an environment that gets built up over time as packages state their requirements. Since a clean of the chroot would blow away my sysroot, I don't want that to happen and go to great pains to insure that all the config files default 'clean' to false and all command lines have --no-clean. I suppose I could copy the sysroot out after the build and back in before a new build, but that just seems hokey...
so is there something WRONG with --no-clean? Does that not meet your requirements?
No, I see nothing wrong with --no-clean (although I prefer setting the 'clean' option to false in the config file). I was just trying to explain my point-of-view (which admittedly is not the norm) so when I submit a patch, those on this list can see why it might be useful.
Clark
On Wed, 2006-05-10 at 14:35 -0500, Michael_E_Brown@Dell.com wrote:
Future: One future direction I'd like to take this is a parallel mock that can prep/build multiple configurations at the same time to try to amortize the cost of prep stage by running prep of one environment in parallel with build of a different configuration. Currently, it is taking me an hour to build 16 sets of RPMS (5 SRPMS per set), and I am hoping to get this down. We have already implemented squid and some other measures to try to speed things up.
parallelizing mock will NOT happen in the fedora mock branch. Period.
Distributing out the items like that are suited to plague, not mock. Adding the features into mock is putting a lot of complexity where it is not needed.
with regard to not cleaning the chroot b/t rebuilds: If you want to do it for the srpms then pass --no-clean and pass in a series of srpms. But breaking the expectation to the user that the chroots will be completely pristine is not safe and, to me, violates the purpose of mock.
-sv
buildsys@lists.fedoraproject.org
-
Clark Williams -
Michael E Brown -
seth vidal