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.
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
- 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
- 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
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/ ?
: 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
CentOS-devel mailing list