On 03/10/2011 10:12 AM, Zenon Panoussis wrote: > > On 03/10/2011 04:12 PM, Manuel Wolfshant wrote: > >>>> The complexity of this stuff is beyond what you are able to parse. > >>> So, what I'm saying essentially is this: would you care to make the >>> de-branding and building process fully open, so that others can copy it, > >> Johnny Hughes has already provided the info and the scripts . See >> http://lists.centos.org/pipermail/centos-devel/2011-February/006735.html >> and later messages > > Are you referring to http://people.centos.org/hughesjr/buildsystem/ and > http://mirror.centos.org/centos-4/4/build/distro/tmverifyrpms ? Indeed, > I had missed those. > > But I was talking about "de-branding and building". For example, it has > been repeated over and over again that most changes are made in the build > root, not in the SRPMS themselves, but where can I find information about > the de-branding which actually *is* done in the SRPMS themselves? I could > find out by installing all the RH SRPMS in one directory and all the CentOS > SRPMS in another and diff'ing the two, but I assume there is already a list > of all the (known) modifications that are needed for de-branding. Has this > list been published somewhere? > 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 signed by a key that says Red Hat, Inc) and we do not rename it as this will cause 3rd party drivers not to install. (Also noted in our FAQ). These packages that are CentOS modified are also listed in the release notes. http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.5#head-b412468e15231f72d472f3aa48c4862f7f83315d As far as reapplying our patches again to a new SRPM when released from upstream, that is EXACTLY how I do it. I first install the old CentOS SRPM. I go to the rpmbuild directory and I move SPECS to SPECS.old and SOURCES to SOURCES.old. Then I install the new upstream SRPM. I copy any patches (or other sources) that have "centos" in the name from the SOURCES.old directory to the SOURCES directory. I then look at the old spec file and the new spec file in VI using vsplit and copy the portions that need to be changed into the new spec file (usually add a couple of centos patches). Then I rpmbuild -bp and see of the patches still apply. If they do apply, I use mock to build to new SRPM into RPMs ... if the patches do not apply cleanly I redesign the patches to apply on this version, then build. If I need to figure out what changed in the old centos spec file, I will install the old upstream package and diff it against the original. There is nothing magic ... if you have the .centos SRPM and the upstream SRPM, then you have everything I use. If you can set up mock and point it to the current centos tree, then you have the build system I use. The host OS I use for the mock builder is CentOS 5, latest updates. > Likewise, many of the changes to the build root - hidden dependencies etc - > are likely to have been documented somewhere. Sort of "note to self: need > to install external xyz from Fedora NN before building abc". Couldn't that > documentation be made public and easily accessible? It has been made public: http://lists.centos.org/pipermail/centos/2011-February/106570.html But, you need to understand that the list is fluid. If a package does not build because of a hidden build requirement, that is a bug. You have to figure it out to get it to build, but the next time you build that package you will likely NOT need to change the build root as they will likely have fixed the issue by then. We first try to build every package in a mock build root that it builds on it's own ... only if it fails do we look at why and make changes to the build root. Every time we do it, it is unique to that specific situation. It is likely never to be repeated again. > That last part, "easily accessible", is just as important as "public". > There might be lots of tidbits of information on this list, but finding > them is a drag. > Why is that important. Red Hat did not tell me how to build it. The purpose of the CentOS Project is to produce an operating system that you can choose to use or not to use. It is not to tell someone else how to produce an operating system. Why should I tell someone how to build a replacement OS to CentOS. That makes no sense at all. > Finally, I can't find any details on the process of comparing RPMs, apart > from tmverifyrpms that you just pointed me to. What needs to be compared, > apart from size? What is the definition of "good" or "good enough"? > The file tells you what we use. It tells you the conditions that produce a FAIL. > If simple things like that, information that already exists, were to be > gathered in one place, the sharing of knowledge that I was talking about > would already be a fact. -------------- 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/2ced9231/attachment-0007.sig>