Les Mikesell wrote: > On 2/23/11 4:59 AM, Karanbir Singh wrote: >> I am not sure how to say this any other way, its been said many times >> over and over again : we dont use any super magic juice anywhere, its >> mostly just mock in a for loop. Lets assume that there still exists some >> fear and doubt somewhere about the process in exact terms. > > If it is just mock in a for loop, then wouldn't spreading it over more machines > be guaranteed to make it complete faster? And if you drop the problem in enough > people's laps, maybe someone will come up with a better automation to > reverse-engineer the RHEL binaries to predict the correct build order and the > right missing libraries. I'm too dumb to do it, so don't bother pointing that > out (as Johnny likes to), but it doesn't seem like an impossible problem - or > one that should be done case-by-case, manually. > You should have few things in mind. My envisioning the rebuilding process is: 1. It was pointed out that they (have) run first mock loop with default/basic environment and selected non-building SRPMS for further analysis and problem solving. They will not re-run SRPMS that can build until they start the final build. 2. When you deal with hidden dependencies, what comes to my mind is to first see dependencies from Fedora12(+) packages by *manually* extracting and comparing .spec files one SRPMS at the time (everybody from team was assigned part of the non-building SRPMS). 3. Dependencies that are found to be missing are added to the building list, and if there are no SRPMS for them bug is filed to Red Hat and then I guess they add the SRPM from Fedora and reconfigure the .spec file, or maybe wait for Red Hat to publish missing SRPM. 4. SRPMS that have dependencies that will not build left for the end. 5. For those SRPMS that only have missing dependency, they start comfiguring mock config that will allow them to build that SRPMS. 6. Built RPMS from item 5 are then compared to the RHEL original. If they pass the test, their mock config if filed for final build and package is marked solved. If RPMS are not the same as RHEL's, they have to, again manually, to find why, what is different. This comparing is mostly done one by one, as soon as one of the team members thinks (s)he finished it. As you can see, there is no much automation going on except for few initial runs, just hard manual labor and frustration. I have tried to compile many packages for CentOS 5.x that depend on much newer core files, and finding out what packages I also need to recompile from Fedora was highly frustrating, and I was just using known dependencies from existing .spec files. Certain packages (especially their newer versions) would have as much as 15-20 dependencies (6-7 layers of dependencies deep) until I would hit some core package I was unwilling to change. And then I would start with older package version hopping that they do nor require those core packages. It would take me even 10-12 hours (until I learn how to cut it shorter), for a single package. Ljubomir