[CentOS-devel] progress?

[Ljubomir Ljubojevic]

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