----- Original Message -----
Well, I would say that the root cause of the problem is that they are somehow manually adding things to the buildroot for these packages. Why or how it happens (as in the process) I have no idea.
If all packages had to build in an automated system, if that automated system had to have one minimum build root and if nothing was allowed to be installed in a buildroot external to the spec file then this sort of thing could not happen.
Obviously they have a way to do some or all of the following:
- Add some kind of "hinting" to the build system that is external to
the SRPM.
- A manual way to add packages from inside the build root if the
package fails to build ... then rerun the package and not update the SPEC after completion.
- Varying minimum buildroots for specific packages that do not follow
the normal minimum buildroots.
So, if someone could provide a build system that would allow altering of build requirements outside of the SPEC file, in such a way that those build requirements were recorded for later use, that would be useful to the CentOS maintainers? What if the build system wasn't mock?
I've been considering doing a rebuild of RHEL this way using rPath's "rMake" build system. The build system is meant to create conary packages, not rpm, but having it produce rpm artifacts as part of a conary package is trivial.
There's a little bit of work to be done (mostly to parse spec files and pull out the build reqs which *are* in the SPEC file, which should be easy), and it's a pretty significant change from how you guys are building things now, but it seems like the appropriate time to toss the information out there just to see if there's any interest. (There a decent chance that I'll be working on this within the next couple of months regardless of interest, but knowing that someone else might contribute or benefit from it helps for motivation...)
--Andy