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. > 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. > > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > >