On 09/15/2011 12:51 PM, Manuel Wolfshant wrote:
> On 09/15/2011 01:34 PM, Xavier Bachelot wrote:
>> On 09/15/2011 12:18 PM, Manuel Wolfshant wrote:
>>> On 09/15/2011 12:34 PM, Marcus Moeller wrote:
>>>> The centos-cr repository should only be unsed during transition phase
>>>> from one minor to another. The package will be removed once the next
>>>> minor is release, and re-appear on next transition. (hope I said it
>>>> right, Karan
>>> This was the first approach but it was changed. The implemented approach
>>> is for /cr to remain in place, the repository links from the repo
>>> definition will point to the new URL automatically. However the
>>> repository will be populated only during the transition phase of a new
>>> minor release ( i.e for instance after RHEL 5.8 is out but before CentOS
>>> 5.8 is released ).
>>>> So the cr release package is not meant to be included in kickstart by
>>> that is true. It is useful only during the transitional phase between
>>> RHEL's launch of a new dot release and CentOS catching up.
>> What's wrong with always having the CR repo installed and enabled ? It
>> might be empty outside of transition periods, but this shouldn't hurt,
>> right ?
> right. the reported issue here is that they are trying to import the
> centos-cr package via the kickstart and there is no such package yet in
> CentOS 5.7
Great, so this should be easily fixable once we've reached a consensus
this package is needed even for otherwise empty centos/x.y/cr.
Count me as +1 for this.
As a workaround for the possibly missing package in the kickstart, one
can still add the '--ignoremissing' option to the %package directive.
>> My understanding is there is no QA difference between a package
>> pushed to the updates or one pushed to the cr repo, thus base + updates
>> + cr repos should stack up nicely.
> that is correct. Actually the process is quite simple, packages are
> first pushed to the CentOS X.n/cr/ and then hardlinked to the Centos
> X.n+1/os ( or /updates, depending on the origin)
Thanks for your answer.
CentOS-devel mailing list