[CentOS-devel] Updates from today

On 03/10/2011 07:55 PM, Nico Kadel-Garcia wrote:
> On Thu, Mar 10, 2011 at 7:18 PM, Johnny Hughes <johnny at centos.org> wrote:
> 
>> Why do you keep talking about a SCM system.  Everything you want to know
>> is in the SRPMS.  If you want to create a git repo of them, have at it.
>>  You like SVN better, use it.  CVS your thing, use that.  Look for
>> .centos files and pull them in (that and the kernel is all we change).
>>
>> I work with SRPMS, not with an SCM system.  I like SRPMS, they are a SCM
>> system of their own.
> 
> Because they're really not. Patches can be altered, and .spec files
> altered, without any logging or notification of the change. Release
> numbers and revision numbers are hard-coded, not trackable.
> 
>> We do not change what upstream has in their SRPMS (except when we have
>> to) ... we don't even unpack them unless we need to change them.  We
>> submit them to mock to build.  Every patch we create, every change we
>> make, it is in the SRPM.
> 
> That's..... a pretty odd approach. Not inconceivable, but *exactly*
> the sort of informaiton not in the "do it yourself, it's easy"
> approach.
> 
>> Why is this so hard to understand?
> 
> Because it's amazingly poor software management. SRPM's are binaries
> and make change tracking quite awkward, and rely entirely on the
> developer to consistently report changes in the %changelog.
> That's..... really awkward.

It is not awkward at all and it does not require anything.

diff -uNrp <original>.spec <modified>.spec > spec.diff

diff -uNrp SOURCES.old SOURCES > sources.diff

Now you have everything.

People making the SRPM don't have to REPORT anything, you see it right
there.  The vast majority of our changes get rolled in over and over
exactly as they are after the first time we create them.  We are not
making technical changes.  PatchA just gets moved from the old one to
the new one and reapplied, etc.  The whole goal is NOT to change anything.

Red Hat does not give us an SCM to look at, yet we seem to be able to
build the software.

> 
>> If we were maintaining changes in 2500 SRPMS per distribution (times 3
>> or 4 distributions), we would do it in an SCM program, but since we just
>> BUILD the vast majority of these packages without changes, maintaining
>> an SCM of 10,000 packages when we change less than 1% of them does not
>> make much sense.
> 
> No, no, you'd just SCM the ones  you alter, and the build system
> (which needed design to provide a bootstrappable environment.)
> 

We build software, we are not it the business of teaching you how to
build software or producing a something that makes it so everyone can
rebuild their own distribution.  Our goal is not a reproducable system
so YOU can build software, it is for US to produce software.  If you are
looking for a distribution that teaches YOU to build things, get Gentoo
or Linux From Scratch.

>> You have the SRPMS, you have example config files, you have the mock
>> that we use, you have the script that we build the software tree with,
>> you have the file that we use to compare RPMs with upstream.  Those are
>> what we use.
>>
>>> I've really been hoping for public access to the build structure. "You
>>> can do it yourself" is not as helpful as the kind of public access to
>>> build structures that Dag publishes, and has been suggesting.
>>
>> The build structure is NOT necessarily a public machine.  The machines
>> that get built on do not necessarily belong to CentOS.  My company, for
>> example, provides some resources that I build on.  You can not have
>> access to my company's internal network or their machines.
> 
> Excuse me, I didn't say it should be. But access to the /etc/mock
> files, *in the SCM I just described*, would be helpful.
> 

The mock files are default and point to the default CentOS trees.  I
gave you an example mock file.

>> Dag changes SRPMS and source code ... we rebuild someone else's source
>> code.  That is why we don't maintain an SCM.
> 
> But you do change them! By your own admission above, you've altered
> 100 packages. That's plenty to justify an SCM.

People are already bitching that it TAKES TOO LONG to get the software
and what you want to do is add more things to the process to make it
easy for you to reproduce what we do.  This conversation is about what
makes it easier for you to rebuild the upstream sources and has nothing
to do with what the purpose of the CentOS Project is.  What you need to
do is start your own project called "Enterprise Linux from Sources" and
your goals need to be to design, maintain, and teach someone exactly how
to rebuild the upstream sources ... those are not the goals of CentOS.
It would be a good project, it is just not THIS project.

-------------- 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/20110311/4f64159b/attachment-0003.sig>