On Friday, February 18, 2011 12:35:16 pm Larry Vaden wrote:
There's a need for current BIND, et al and RH's policy of backporting takes time and puts perhaps millions of systems at risk.
What exactly is so necessary about having 'current' BIND, and what will break or change in an unexpected way when BIND is brought current?
<quote from top management of Internet2 security> It's fundamentally wrong for RedHat to attempt to backport security patches for such a fundamental service. I'd cuss a blue streak about this point, in fact, except that I don't want to trigger the anti-cuss features at Dr. Vaughn's place of employment. </quote from manager of Internet2 security>
You keep quoting this, but, it seems to me Red Hat has done very well in the market at a time in which the market was difficult. They can't be doing to many things that are 'fundamentally wrong' or they'd go out of business (since they aren't a monopoly). Details, man, details.
However, the CentOS list is the wrong place to address this; the stated goal of the core CentOS repositories (this excludes CentOSPlus) is to be as close to upstream as is possible in building from the source; bugs and all. Address the bug upstream; it will then come downstream. That is and has been the CentOS credo pretty much as long as there has been a CentOS, as far as I can recall.
As a further comment, it is not easy to get this close to the upstream at the binary level. Things are better than they used to be back in the days of beehive and highly customized specialized buildhosts (I could find my archived message from Jeff Johnson about it, and I probably could share it here since it's been over ten years, but I have more important things to do after I'm finished with lunch).
But things are not perfect, and Red Hat does not make public the complete specs on its buildsystems. Like I say, it is better now than in the good old days, thanks in no small part to the Fedora project's open infrastructure, but there are still niggles to do to get things to build.
Troy has documented on the SL list about some of those niggles; I've been reading the release notes, and they are revealing about the process, and about some fundamental differences between SL and CentOS, both the distributions and the projects. Anyone curious about those differences, read through the archives of all the lists and see them for yourself; I'm not going to summarize here. Suffice to say that I don't think either approach is the One True Way to an EL rebuild; they are just different.
At one time I thought they should join forces, but even as talented as all the folks involved are, it wouldn't be the greatest of ideas; in a way, thanks to how open the processes of both distributions are (yes, the CentOS process is more open than it could be!), they already have joined forces, just as sovereign allies, instead of parts of one big project.
Johnny has posted a link to the buildsystem 'things' for C3,4,and 5; 6 isn't up there, probably because it's not finalized.
I was there in the old days of waiting on a new RHL release; this process is scads more open than the process then was, that is for sure.