On 10/02/11 20:39, Troy Dawson wrote:
> For production systems, we are recommending that you do a fresh install
> after the final release.
>
> For machines you don't care about as much. Yum will update you to the
> final release.
>

OK, understood.

>> I know how this is handled for Fedora, but I guess what I'm not clear on
>> is whether SL is updating package EVRs with each package rebuild (which
>> would mean a simple yum update follows the development), or keeping them
>> identical to TUV shipped packages and over-writing (which yum wouldn't
>> notice)?
>>
>
> We are done with that phase. While we were in the Alpha stage TUV
> packages changed without being renamed. All of our SL packages, which is
> what we are working on during the Beta phase, will have their release
> numbers increase so that yum is able to update to the latest. So you
> shouldn't have to worry about that.
>

OK, thanks, that clarifies things.

>> Also, while installed systems using the SL packaged yum repo definitions
>> will seemlessly move from the 6rolling to the 6 tree as the repo
>> packages are updated, this isn't the case for machines deployed from
>> cobbler without manual intervention at the right point on the cobbler
>> server, as the cobbler OS repo location is manually specified. What
>> might help here is if there was a 6 link pointing to 6rolling through
>> the beta and RC phase. Is that possible?
>>
>
> I'm not quite sure what you mean by the link.
> But the 6rolling area will have the same packages as the 6.0 area. The
> 6rolling won't just sit at Beta or one of the release candidates.
> As we move out the release candidates, we move everything from our build
> area, to the rolling area, test there, and then move it over to the 6.0
> area, and test again. So at the release candidate, and release phase,
> 6.0 and 6rolling will be the same.
> Or is there something else that would make cobbler happier?

Right - I wasn't very clear. Cobbler makes a mirror of a repository URL 
locally on the cobbler server, and then provisions machines from that 
mirror. And in that provisioning process, the provisioned machines are 
set up to look at the cobbler mirror for the corresponding yum 
repositories.

So, assume we set up cobbler today to mirror 6rolling. Without 
intervention, the cobbler server would continue to mirror 6rolling after 
the release which will presumably continue to evolve in an unstable way 
as 6.1 starts to be built etc. Only by manually switching the cobbler 
mirror to look at 6.0 immediately after release will it be ensured that 
the provisioned machines are receiving packages from 6.0.

If there was a link from 6.0 to 6rolling now, it would be possible to 
configure cobbler to mirror the 6.0 URL now, which would correspond to 
6rolling until release time, and then 6.0 after release time without any 
manual intervention.

Cheers,
Jonathan.