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