On 02/19/2011 05:17 AM, Johnny Hughes wrote:
... and we change things OUTSIDE the SRPM to fix the problem.
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.
Since our goal is NOT to change upstream packages at all, this would not show up in this "SVN" or "GIT" tree of all the packages ... since we do not change (or want to change) the package that upstream has produced. In any other project besides CentOS, the fix would take 1 minute, it would be to add a "Build Requires: perl-XML-Parser" to the spec file in the SVN repo and regenerate the SRPM package.
So, this time consuming tree that you want guys want us to create is not worth a hill of beans and adds nothing for the vast majority of packages, since the SRPM is unmodified from upstream.
<delurk/>
This is a very helpful explanation; thanks Johnny.
How are these changes codified? Is there, say, a 'BRPM' file, with a:
BuildRootRequires: perl-XML-Parser
line in it? If these files do exist, they could possibly be useful in a git tree for some. Some may call those files the CentOS Special Sauce.
A script to automatically file upstream bugs based on those files' check-ins would seem like a potential timesaver.
Upstream SRPMS + CentOS Special Sauce + mock = buildable distro? That would be an awesome start for a CentOS Spins project. A scientific spin, for instance.
Just thinking out loud. No doubt others have already gone further.
-Bill