I did understand it the first time, but thanks again for the further clarification. This kinda illustrates my point. Couldn't you have a different repo with these updates maintained by other community members, under the guidance of the 'core'. Ppl could decide whether to trade-off security vs compatibility/reliability. I suppose your counter argument there is that there is nothing stopping that happening outside of CentOS project.
Anyway, I am sure you have better things to do than argue the toss with me on a Sunday! ;o)
Anyway, I am sure you have better things to do than argue the toss with me on a Sunday! ;o)
From: Johnny Hughes <johnny@xxxxxxxxxx>
To: CentOS mailing list <centos@xxxxxxxxxx>
Sent: Sunday, 9 August, 2009 13:54:50
Subject: Re: CentOS Project Infrastructure
Johnny Hughes wrote:
> Ian Murray wrote:
<snip>
> WRT to the one valid issue that you raise ... let me explain the
> TECHNICAL reason why you can not release these things hodge podge.
>
> First ... Red Hat releases point releases at regular intervals (3-4
> times per year).
>
> Second ... we do not release anything that does not pass our checks and
> is linked to the same libraries as upstream.
>
> Now, when the upstream provider does a point release, that means they
> have released a whole bunch of NEW libraries. It also means that every
> single update that comes out after their point release is built against
> the NEW libraries and not the OLD libraries.
>
> We can NOT build and release the security updates you talk about against
> the OLD libraries that you have installed on your machine (prior to the
> point release) as it will make the NEW updates we are building NOT like
> they are upstream.
>
> We have to build the new updates against the point release instead. The
> point release will either not be done yet (it takes time to build) or in
> testing/qa and not yet released. When we build against it, we will have
> to release all the pieces that are required to also get the updates you
> are talking about.
>
> That is the problem ... therefore, we HAVE to finish the point release
> and get it out before we can build new updates released after the point
> release. This is not new, it has been an issue since the first rebuild
> more than 5 years ago.
>
> People who do not understand the technical issues involved do not see
> why we can't just snap our fingers and put out the packages ... well, we
> can't.
Let me get even a bit more technical.
Firefox-x.y.z gets released after the CentOS-A.b release.
Firefox needs nss-x.y.z-3. The released version of nss before the
CentOS-A.b is nss-x.y.z-2.
No problem, build the new nss-x.y.z-3 first, then build Firefox-x.y.z.
Well, dang, nss-x.y.z-3 needs nspr-x.y.z-99 and nspr-x.y.z-98 is
currently in CentOS-A.b ... so now we need to also build nspr-x.y.z-99.
There is a new version of glibc and gcc in the point release and it
corrects ISSUE #ABCDE in the bugzilla, which impacts Firefox-x.y.z, so
we have to build those 2 things to. They require PackageQ and PackageT
to be rebuilt.
Now, while we are trying to figure out the complex relationships
required to build firefox, would could have been testing and producing
the point release. Add a couple more updates and what you have is a
hodge podge mess of things released at different times.
You are also introducing bugs into CentOS that are not upstream in this
kind of scenario (firefox-x.y.z running against xorg-x.y.z-3 does this
thing ... but when running against xorg-x.y.z-4 it does not).
Hopefully I am making this issue clear.
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
