[CentOS-devel] CentOS 5.7 has no centos-release-cr package

Wed Sep 28 09:32:11 UTC 2011
Xavier Bachelot <xavier at bachelot.org>

On 09/28/2011 11:16 AM, Kevin Stange wrote:
> On 09/28/2011 04:09 AM, Xavier Bachelot wrote:
>> On 09/28/2011 10:39 AM, Ljubomir Ljubojevic wrote:
>>> Време: 09/28/2011 10:31 AM, Xavier Bachelot пише:
>>>> On 09/23/2011 10:25 PM, Johnny Hughes wrote:
>>>>> On 09/22/2011 08:16 PM, Ben Galliart wrote:
>>>>>> On 09/17/2011, Karanbir Singh wrote:
>>>>>>> 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.
>>>>>> Is there any ETA as to when this could be done or at least decided on?
>>>>> There is no need to upgrade anything.  If you installed the package, you
>>>>> are on CR ... then and now.
>>>>> The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when
>>>>> the repo file was released).
>>>>> It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all
>>>>> the RPMS that are required to update from 5.6 (or any other version of
>>>>> CentOS).
>>>>> When 5.8 is released, the RPMs that are part of 5.8 will get put into
>>>>> the /5.7/cr/ and allow people who are opted in to get the updates before
>>>>> the 5.8 release.
>>>>> I think maybe putting the RPM in "extras", so it is easier to install is
>>>>> doable ... but not a huge issue.
>>>>> In fact, I have put it there.  centos-release-cr is now in extras.
>>>> What's the reasoning for putting centos-release-cr in the extras repo ?
>>>> Imho, the package would fit better in either the updates or cr
>>>> repositories (with a preference for the later), because these 2 repos
>>>> allows to get upstream updates and only that, while extras carries a lot
>>>> of packages not coming from upstream. Providing a repository yum
>>>> configuration from within said repository is quite usual for other repos
>>>> and it looks strange to have to use one repo to get the conf for another.
>>> Base repos must reflect what upstream is publishing. Thus, any extra
>>> packages must go elswhere.
>> This package is special, as it provides only yum confs and no binaries
>> or anything else, and is needed to actually get the updates upstream is
>> publishing. To be a bit bold, this is not different than the
>> centos-release package, which is not in extras either.
>> Actually, the cr repo definition could just be added to the
>> centos-release package, possibly disabled by default.
> No, no, no, why do we want to sabotage CR?  Why does everyone hate it so
> much?
> If it's going to be in the base release file and disabled by default,
> now we make it even harder, instead of (easy) "yum install" or (less
> easy) wget into proper place, now you're saying users are going to need
> to edit files or use "yum --enablerepo" to get updates.
> This is an important repo with security patches that could otherwise be
> months delayed.  This should not be something hidden from users.
> I still think it should be opt-out, but I can accept that it is not in
> the mission to break individual release compatibility with upstream by
> default.  Let's NOT intentionally make it harder to install this,
> please, please.
I certainly don't want to sabotage cr and I completely agree it is 
mandatory to close the security updates gap between point releases, and 
as such, I very much welcome the work done on this.

I think at this point my preference would go to have the cr repo 
definition in the centos-release package and have it enabled by default, 
just like the regular updates repo (and actually, I would even say 
extras should not be enabled by default in order to be even closer to 
what upstream provides, but this is a different matter). I said the cr 
could be disabled by default only because some people are of the opinion 
it should be opt-in rather than opt-out, but that's another point to 
discuss. What I'd like to be cleared now is how to have the repo 
definition available, as easily as possible.