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.