[CentOS-devel] progress?

[Johnny Hughes]

On 02/19/2011 01:31 AM, . wrote:
> On 2/18/2011 8:28 AM, Dag Wieers wrote:
>> Everything is available from:
>>
>>       http://svn.rpmforge.net/svn/
>>
>> we have a viewvc front-end and a mailinglist to keep track of changes
>> here:
>>
>>       http://svn.rpmforge.net/viewvc/
>>       http://lists.rpmforge.net/mailman/listinfo/svn-commits
>>
>> And there are mailinglists to suggest changes or discuss packages. But at
>> least everything is shared.
>       I would like to say that in my opinion the system mentioned above 
> sounds better than what there is now, for outsiders.
> 
>      Now, I don't want outsiders to have access to the GPG keys, nor the 
> ability to push out new versions, but being able to see the source tree 
> as it is, and being able to download a mock config + setup instructions 
> would go a long way (again in my opinion).
> 
>      Forgive my naivete, but what is preventing us from doing such a 
> thing? Is this a lack of manpower/resources to set it up, or is this 
> more political as in; we don't want other rhel based distros to steal 
> our juju?
> 

We release our SRPMS, that is our juju.  Every patch is there for the
looking.

I have tried to explain, over and over again.  You guys are trying to
make the process different than it is.

For most projects where RPMS are produced, you are getting an upstream
tar ball that may or may not have a spec file ... you are creating spec
file, you are creating lots of patches to change where WWW pages go or
what directory things get installed in, etc.

That is not the case with CentOS ... all of those changes are already in
the "SRPM Source Tree".  Our #1 goal (by far) is to be able to use that
SRPM package exactly as it is ... to clone it and make our rendering of
it as identical as possible to the original.

For the vast majority of packages, we make no changes.  We rebuild it
and test it.  If the binary passes the test, we use it.  If the binary
does not pass the test we troubleshoot and figure out why it does not
pass the test ... 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.

You have everything you need already in the SRPM.

>      For those about to say, help out or don't; I have helped out. I did 
> a handful of patches last month after reverse engineering the process 
> (http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a 
> month, and none of the bug ids where I posted patches on have had so 
> much as their status changed. Before you jump down my throat on that, I 
> realize the priority was/is Centos 5.6 etc...
> 
>      I do believe that if we had a system similar to what Dag is using; 
> someone in the Centos community would have tried the patches I made, 
> maybe they didn't work and I needed to fix something or maybe they fix 
> it and upload a better version. I think progress would have been made 
> that wouldn't have detracted from the centos-devel's focus.
> 

What makes you think that we HAVE a "split" source tree?

CentOS builds someone else's SRPMS ... that IS our source tree, the
SRPMS that are produced upstream.

We only change a handful of SRPMS (the ones that are labeled .centos).
We are not creating these packages, and in fact it is desirable that
they do not change at all.

We would be creating extra work to break down the SRPMS into their
component parts and create this so called source tree.

What would be the benefit of all this extra work since we do not change
the vast majority of the packages.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20110219/179746e7/attachment.sig>