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-0007.sig>