[CentOS] Could this be an advantage of CentOS over the PNAELV distribution?

Wed Jun 11 17:19:22 UTC 2008
Johnny Hughes <johnny at centos.org>

Luigi Perroti wrote:
> Hello all,
> 
> I understand that when releasing updates the CentOS team strips logos
> and such things from the upstream sources.
> If I'm not mistaken there is also a certain QA process going on before
> the actual releases, at least for major updates like the upcoming 5.2
> version.
> 
> Does this happen also for security updates?

Yes, we QA every update.   However there is much less to look at when 
you are not doing several hundred packages at the same time.

We also do not have a Client and Server and Workstation and AS/WS/ES 
type structure ... or install numbers, etc.  So creating the compilation 
is complicated.

There is a combined comps.xml that has to be created which is 
significantly different than the upstream one.

> 
> 
> Since I don't mind the small delay from the upstream releases I was
> wondering if the additional QA process could actually be an advantage
> over the PNAELV distribution.

Yes ... for example in the 5.2 QA process, we have already found and 
worked around several bugs ... like:

RHEL-5.2 rebased gtkhtml3 which renders custom software built against 
the old version useless until recompiled.  I have produced a 
compat-gtkhtml3 for CentOS-Extras.

There is a bug with nss_ldap and bash32 ... I created a new RPM for the 
nss_ldap that is currently in our testing repo.


> This could be even more true if the QA isn't only related to CentOS
> specific changes but it's done even for practically untouched updates.
> 

Even if we don't change anything, we have to verify every binary because 
red hat does not release the "buildroot" logs for each RPM.  There are 
frequently "hidden build requirements" (that means things in the build 
root that are linked against, but not listed as a BuildRequires in the 
SRPM).  We find these by seeing what the upstream binaries link against 
and then adding them to our build root and rebuilding.

> Is this assumption correct?
> 

We check every binary, not just the changed ones ... because we rebuild 
everything and they all can have hidden build requirements.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20080611/eb487d7b/attachment-0005.sig>