On 02/19/2011 06:34 AM, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 4:17 AM, Johnny Hughes johnny@centos.org wrote:
For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package.
Johnny,
Although one can read on this list that you are no longer with the CentOS Team, we are glad to hear that you are still on the CentOS Team.
Is what you describe above what Lamar describes on this list as sniggles?
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:
1. Add some kind of "hinting" to the build system that is external to the SRPM.
2. 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.
3. Varying minimum buildroots for specific packages that do not follow the normal minimum buildroots.
What do you think is the root cause of such things @ the upstream?
What causes it is that they do not require the SRPM to stand alone and do the installs on an automated, single setup, single minimum buildroot system.
Why? No idea.