[CentOS-devel] progress?

[Johnny Hughes]

On 02/19/2011 04:29 AM, Johnny Hughes wrote:
> On 02/18/2011 01:00 PM, Les Mikesell wrote:
>> On 2/18/2011 12:48 PM, Lamar Owen wrote:
>>>
>>>> In a truly open system, you don't need to 'join forces' to take
>>>> advantage of each others' work.  The version control system will tell
>>>> you everything you might need to know, and the fact that it is open
>>>> means that permission to use it is implicit.
>>>
>>> Perhaps the expression 'join forces' isn't quite right.
>>>
>>> The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure.  At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.
>>>
>>> Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
>>
>> Nobody said it was trivial or easy.  No major software project is.  But 
>> the open ones put all their tools in a version control system that 
>> anyone can access and duplicate.  And the successful open ones find that 
>> some of the people who do access and duplicate their work improve on it 
>> and make their improvements available.  Is anything like that happening 
>> here?
>>
> But the VERSION CONTROL SYSTEM would need to be implemented BY upstream
> not us.
> 
> Our stated goal is to NOT change anything that we don't have to change.
>  We ONLY make changes to the packages as required to remove trademarks
> ... we add NO CHANGES to fix the packages.
> 
> It is our goal to NOT HAVE ANY CHANGES.
> 
> Therefore a VCS at the package level for our projects is worthless
> (except for the packages that we have to change to remove trademarks).
> 
> That is what no one is understanding here.
> 
> We do NOT change the packages (the SRPMS), therefore there is nothing
> inside the packages to track.  If you have the SRPM, you have the source
> code that would get imported into the VCS ... it would then also be
> rebuilt exactly like it was to submit it to the build system.
> 
> For packages that are not changed at all (the VAST MAJORITY in the case
> of CentOS), this splitting of SRPMS into a VCS and then reassembly from
> the VCS into an SRPM adds nothing to the overall process. In fact, it
> only adds a potential spot to do unneeded actions that might introduce
> errors into the packages on reassembly.
> 
> So, this VCS at the CentOS level is extra work for us with no added
> benefit to producing packages.
> 
> The vast majority of the time, we are working directly with SRPMS, and
> not a VCS.

Something else i want to point out here is that IF you need to adjust a
build root for a package for version x.y.z-1 ... when x.y.z-2 comes out,
it may or may not need that same change.  And in fact, we try building
it first with NO changes in the build root to see if it will build, if
it does not then we would look at what is in (or what is extra in) the
compare process and add or remove things to get the correct linking.

There is no magic secret sauce or magic VCS here to be kept over time.
It is brute force build, compare, adjust, build.  It is good only for
the one iteration for which it is performed.  The next time a new
package is built, we do it in a virgin way to try and reproduce it
exactly as the SRPM requires.

It is no harder than build it in mock ... check it ... manually modify
the build root with some commands ... if required (if the package fails
the compare).

You guys act like we are doing magic here, we are not.

-------------- 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/a4d09b92/attachment.sig>