On 09/17/2011 01:23 PM, Karanbir Singh wrote: > imho, it would be wrong to force people to get the centos-release-cr by > default, specially in the centos-5 lifecycle since it would be a drastic > change in the way things work and what people's expectations might be.[1] I honestly don't think that most users of CentOS have or should have the expectation they are going to stay with 5.6, for example, when 5.7 comes out, for security reasons and also because yum forces their upgrade. The RPM repos are replaced with new repos upon release, which don't retain the versions of packages that were available in previous releases. It's not really viable to stay on 5.6, and current operations assume you won't. The only real way a user of "yum" can tell is that they suddenly receive a new "centos-release" package in their update. > If there is a desire to have this be default behaviour then the split > should, again imho - and open to discussion, be at the ReleaseVersion > level - as implemented in the yum client interface and delivered via the > mirrorlist / mirror network. To expand on that, using CentOS-6 as an > example: > > - change mirror.centos.org/centos/6/ to _be_ CR; ie, the updates/ repo > under there would inherit the CR content automagically, and deliver repo > metadata to cover all ( CentOS-6 os) + ( CentOS-6 updates ) released > rpms. Would be tricky handling the /6/os/ repo, but we can work > something out. > > - change mirror.centos.org/centos/6.0/ to only deliver content that is > 6.0 specific, ie: what we do now with a point release. /6.0/os would > reflect install media shipped as CentOS-6.0-*bin*.iso; with > /6.0/updates/ only delivering updates released during the 6.0/ cycle. I am generally in favor of having a constantly rolling release at 5/ and 6/ instead of worrying about having the media ready. The vast majority of our installations are going to be updated from one release (5.6) to the next (5.7) and we perform PXE-based KS installs with the intention of having them start out fully updated. If I never saw another ISO produced again, it would not be a problem for how I use CentOS, and I certainly think that getting new installs rolling on new media is of much less importance than keeping existing installs secure and stable. As far as the content at 6/, I see the following making sense as a release process: 1) Upstream releases 6.1 2) All important update packages are produced and placed in 6/updates/ 3) While updates continue, 6.1 installer, images undergo QA and release 4) Full release tree is inserted at 6.1/ 5) Upon release, packages shared between 6/updates and 6.1/os are hardlinked together 6) After some mirror stabilization, 6/os is symlinked to 6.1/os 7) After another mirror stabilization 6/updates is cleared of pre-6.1 packages 8) After the usual waiting period, trees for 6.0 are moved to the vault and deleted from mirrors. I would say that default installation $releasever should resolve to "6" and as usual, if there's a desire to fear any future 6.x releases, that's an exercise to be undertaken manually. > Now back to the question on hand, centos-release-cr in 5.7.. > > Perhaps the best place for the centos-release-cr is in the updates/ > repo, rather than the /cr/ repo, since that way it would further reduce > the barrier for people to opt-in, a simple 'yum install > centos-releae-cr' would get them on the track, and keep them there till > such time as they want to opt-out. This is, as I had suggested on IRC, what I would prefer. > The important bit being that we keep the CR repo opt-in, and do our best > to create awareness of this repository, what it hopes to achieve and how > people can get it installed on their machines. We provide supported "managed" Linux, so we want this to CR to always be enabled so that users get the expected result that if they update their system manually, they get security updates, and if we update, we don't have to worry about the opt-in process. > In terms of install-time-availability, we only really QA with the OS > repo's; adding or removing other repos is left upto site specific > implementations. However, if the centos-release-cr rpm was available in > the updates/ repo, it would clear this issue up for you ( I'm presuming > that you install with the updates/ repo present with a --repo line in > your kickstart ). Yes, I think a fully up-to-date installation is one of the primary goals of having the CR included in the kickstart. > Now w.r.t release version of centos-release-cr, its at 5-6.el5.centos > since that reflects the state of CR. So you can see what condition of > the machine is. Even if you were to install centos-release-cr today, it > should still be 5-6.el5.centos since that was the last cr/ repo > populated. With the first rpm release into 5.7/cr/ would come the > centos-release-5-7.el5.centos rpm; which should get updated to everyone > who has opted-in, and would then correctly reflect the status of the > machine ( in that there would be a centos-release-5-7 and a > centos-release-cr-5-7 ). I'd say the version number is unimportant since the actual repo configuration is not version-dependent, so centos-release-cr-5-100 would be fine to avoid any possible confusion. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20110918/106b8874/attachment-0007.sig>