The "progress?" thread carries questions, explanations and arguments, a healthy portion of mud and a bit of fud for spice, but not much is coming out of it, apart from the volume of the conversation itself.
So I'll make an attempt at being constructive. If I end up demonstrating my complete ignorance of the build system while also offending people at the same time, just take a moment to bash me and at least enjoy that.
There are essentially two crowds here, the one bigger, the other more indispensable: the "we are tired of waiting, WTF is holding up our distros?" crowd and the "we are working our asses off for you and we're sick of your complaining" crowd. Both are right in their own minds, but both have also fully valid arguments, objectively speaking. No solution will work, unless it somewhat meets the needs of both crowds.
The most repeated argument from the impatient is that of security updates. The most repeated argument from the patient is that of binary compatibility and the hassles of achieving it.
Now I wonder, what's the difference between the 5.5 and the 5.6 build root? I don't know, but I am assuming there is none, because any random package in 5.5 must be upgradable to 5.6 without pulling in an entire distro as a dependency. Hence, it should be possible to build security updates from 5.6 in the 5.5 root and they would be compatible with both 5.5 and 5.6.
So then, assuming that that is true, why can't security updates from 5.6 be compiled in the existing 5.5 root together with any specific dependencies they might have, and be released in the 5.5 tree? Doing so would put the CentOS and RH repos out of sync, but would still preserve binary compatibilty. And repo sync has never been a CentOS goal anyway.
In other words, we would get package-1.2.3-1.x86_64.el56.rpm in 5.5 and later that very same package would appear in 5.6 as well. yum has no problem with that. The impatient crowd gets security updates. The patient crowd can then take its time to create a quality 5.6 distro. Nobody gets hurt in the process.
And there's another similar compromise between speed and perfection, which I suggested already earlier: just release the repo first, as soon as it's ready, and only then start working on the installer ISOs. Then those who already have 5.5 installed and want to upgrade, can just do so. Anyone who wants a fresh 5.6 in a hurry, can install 5.5 and then upgrade it. Those who want a comfortable out-of-the-box 5.6 installer, are more willing to wait. All in all, this way the users can get something faster without the developers having to make any extra effort, so everybody's happy, or at least a bit happier than before.
Can somebody please tell me why any of this wouldn't work?
Z
On Wed, Mar 2, 2011 at 9:04 PM, Zenon Panoussis oracle@provocation.se wrote:
Can somebody please tell me why any of this wouldn't work?
Z,
The most relevant answer I can think of is:
Karanbir Singh wrote "all updates to the /5/ tree are monitored and anything which has a remote or local exploit will get pushed into the /5/ tree; things in 5.6 and against 5.6 that dont meet that criteria wait for 5.6 release. build order, linking, inheriting upstream testing etc etc to blame"
Stephen Cox wrote:
On Wed, Mar 2, 2011 at 9:04 PM, Zenon Panoussis oracle@provocation.se wrote:
Can somebody please tell me why any of this wouldn't work?
Z,
The most relevant answer I can think of is:
Karanbir Singh wrote "all updates to the /5/ tree are monitored and anything which has a remote or local exploit will get pushed into the /5/ tree; things in 5.6 and against 5.6 that dont meet that criteria wait for 5.6 release. build order, linking, inheriting upstream testing etc etc to blame"
Z has very interesting e-mail address. Oracle on domain without web site. Hm.....
on 3/2/2011 11:04 AM Zenon Panoussis spake the following:
The "progress?" thread carries questions, explanations and arguments, a healthy portion of mud and a bit of fud for spice, but not much is coming out of it, apart from the volume of the conversation itself.
So I'll make an attempt at being constructive. If I end up demonstrating my complete ignorance of the build system while also offending people at the same time, just take a moment to bash me and at least enjoy that.
There are essentially two crowds here, the one bigger, the other more indispensable: the "we are tired of waiting, WTF is holding up our distros?" crowd and the "we are working our asses off for you and we're sick of your complaining" crowd. Both are right in their own minds, but both have also fully valid arguments, objectively speaking. No solution will work, unless it somewhat meets the needs of both crowds.
The most repeated argument from the impatient is that of security updates. The most repeated argument from the patient is that of binary compatibility and the hassles of achieving it.
Now I wonder, what's the difference between the 5.5 and the 5.6 build root? I don't know, but I am assuming there is none, because any random package in 5.5 must be upgradable to 5.6 without pulling in an entire distro as a dependency. Hence, it should be possible to build security updates from 5.6 in the 5.5 root and they would be compatible with both 5.5 and 5.6.
Not necessarily. If a version upgrade comes with important changes like glibc or kernel updates, then any security updates AFTER that update should also be built on the newer buildhost. RedHat and all that depend on them do not necessarily support pick and choose updating. You can get that from RedHat for a fee, but no one here at CentOS has that much time available.
So then, assuming that that is true, why can't security updates from 5.6 be compiled in the existing 5.5 root together with any specific dependencies they might have, and be released in the 5.5 tree? Doing so would put the CentOS and RH repos out of sync, but would still preserve binary compatibilty. And repo sync has never been a CentOS goal anyway.
In other words, we would get package-1.2.3-1.x86_64.el56.rpm in 5.5 and later that very same package would appear in 5.6 as well. yum has no problem with that. The impatient crowd gets security updates. The patient crowd can then take its time to create a quality 5.6 distro. Nobody gets hurt in the process.
This would work sometimes, but not EVERY time...
And there's another similar compromise between speed and perfection, which I suggested already earlier: just release the repo first, as soon as it's ready, and only then start working on the installer ISOs. Then those who already have 5.5 installed and want to upgrade, can just do so. Anyone who wants a fresh 5.6 in a hurry, can install 5.5 and then upgrade it. Those who want a comfortable out-of-the-box 5.6 installer, are more willing to wait. All in all, this way the users can get something faster without the developers having to make any extra effort, so everybody's happy, or at least a bit happier than before.
Can somebody please tell me why any of this wouldn't work?
The installer ISO's are only a small part of the build process. I would think the ISO sync to the mirrors might take longer than the ISO build itself. Only if there are major changes to Anaconda is there a long lead time on ISO's.
-
Ljubomir Ljubojevic -
Scott Silva -
Stephen Cox -
Zenon Panoussis