On 03/10/2011 05:41 PM, Nico Kadel-Garcia wrote: > On Thu, Mar 10, 2011 at 6:31 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote: >> On Thu, Mar 10, 2011 at 5:52 PM, Johnny Hughes <johnny at centos.org> wrote: >>> On 03/10/2011 04:36 PM, Nico Kadel-Garcia wrote: >>>> On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes <johnny at centos.org> wrote: >>>> >>>>> Any SRPM modified by CentOS will have a .centos in the name of the SRPM >>>>> (that is noted in our FAQ). If it does not have a .centos, it is the >>>>> same as upstream. The only exception is the kernel (we modify it not be >>>> >>>> This is quite sensible. Is this documented anywhere? I'm not finding >>>> it in tne Wiki, but admittedly my Wiki expertise is not absolute. >>>> >>> >>> It has been posted on the FAQ in the first comment here: >>> >>> http://linuxreference.com/modules/smartfaq/faq.php?faqid=9 >>> >>> (since 2005/5/14) >>> >>> It is also in the Wiki in question #4 text here: >>> >>> http://wiki.centos.org/FAQ/General >> >> Thanks. It's an answer to somewhat *different* question, so I missed it, but OK. > > On review, it's also lacking detail. The use of the "%{dist}" option > in .spec is a wonderful standardization, and of '%{?dist}" even more > effective by the upstream vendor. It really helps allow developers to > set it in their .rpmmacros and use the defaults when they run it > through mock to build production versions, so I *assume* that your > mock environments are not resetting this. Perhaps a mention that "we > prefer to tweak it by editing the .spec files as necessary, and those > modified .spec files are available at publicly accessible source > Subversion mirror 'http://svnmirror.centos.org".. > 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. 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. Why is this so hard to understand? 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. 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. Dag changes SRPMS and source code ... we rebuild someone else's source code. That is why we don't maintain an SCM. -------------- 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/20110310/2af301e1/attachment-0007.sig>