[CentOS-devel] Updates from today

[Johnny Hughes]

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