Hi, On 09/16/2011 01:54 AM, Ben Galliart wrote: > If CR is the recommended way to get security fixes during transition periods, then I would prefer to have systems opt-in ahead of time during the installs instead of at the last minute. The /CR/ repo is meant to be an opt-in repository. The thinking is that once someone opts into the idea of what the CR repo is, they stay with it till such time as they want to opt-out, and they can do that with a rpm -e centos-release-cr. 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] 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. 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. 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. 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 ). 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 ). Is this version scheme causing more confusion than its clearing out ? Should there be a centos-release-cr-5-7.el5.centos available *NOW* in 5.7/cr/ and in 5.7/updates/ ? - KB [1]: Maybe we got the name wrong, NextRelease might have been clearer on the goals and deliverables of that repo rather than ContinuousRelease. And be easier to spell too :)