I've gotten two suggestions on possible ideas here.

Thanks to Mátyás and Oleg for participating in this conversation!

Mátyás suggested possibly using 'slreleasever' to setup the repo files.  
This would allow for a single repo set, rather than a 'rolling' and a 
'non-rolling' repo config.  Its an interesting idea!  I'm not sure how 
to integrate this with the '7x' repo to allow seamless transition from 
'7x' to '7.0' as I was considering a separate RPM to set the system to 
'7x' rather than '7.0' - in keeping with the SL5 and SL6 traditions.

Are there other community thoughts/suggestions/solutions on this idea?

Oleg has suggested a symlink on the server side.  I'm not entirely sure 
which problem set he is aiming at.  Oleg, may I request further 
clarification?


Does anyone have any thoughts on the release candidate overlap? For SL6, 
with duplicate repos, it was an annoying but solvable problem.  With a 
single repo set, and with a release candidate _not_ linked to '7x' I 
worry.  It is totally possible I'm worried over nothing.....


One of my personal aims for SL7 is to try and make this release easy to 
manage, while keeping the historic SL flexibility.  Am I spending time 
on something the rest of you are not worried over or would this be a 
helpful improvement (if we can solve it)?


Again, thanks to Mátyás and Oleg for their involvement in this process!

Pat



On 07/03/2014 04:19 PM, Pat Riehecky wrote:
> Here is the problem I'm trying to solve. I'll use SL6 as an example:
>
> When a user installs the '6x' config they get an additional yum repo. 
> One for $releasever and one for 6x. While SL6.5 is 6x, you've got two 
> repo definitions for one source.
>
> * Duplicate repos mean duplicate metadata, which makes 
> yum-plugin-security complain.
> * Duplicate repos mean two places to set any custom includes/excludes.
> * Duplicate repos for the same data source is "not what users expect"
>
> Then we add to the mix our rolling tree for pre-release testing.
>
> We _must_ provide a yum repo pointing to '6rolling' as part of the 
> process or users can't really test it. However, we change out the 
> $releasever repo with the 6rolling repo. Aspects of the decision 
> process here predate my involvement, but the crux of the reasoning 
> predates default inclusion of '6x' - push one repo and make sure it is 
> aimed where it should be.
>
> For SL7 I'd like to try and minimize our duplicate repo "problem" 
> using yum's internals.
>
> Yum uses /etc/yum/vars/ as a simple way of creating key/value pairs 
> for setting variables.
>
> For example run the following command on an SL6 box you manage:
> echo broken > /etc/yum/vars/releasever
>
> your next 'yum update' should complain about how urls with $releasever 
> now fail due to 'broken' not being a valid part of the url.
>
> Make sure to remove the file afterwards.
>
> With this in mind we could use the same basic yum repos for SL7, but 
> make the 'yum-conf-sl7x' simply set $releasever to '7'. This provides 
> instant compatibility with CentOS and shouldn't put much overhead on 
> any 3rd party repo.
>
> The result is super elegant with a flaw.  And what a flaw!
>
> For the release itself you'd only have 3 repos: sl, sl-security, 
> sl-fastbugs. When yum-conf-7x is installed they would automatically be 
> converted 7 from 7.0 without breaking any 3rd party repos installed. 
> And by using yum internals we don't need any extra tools or really 
> much scripting. User customization to the yum repo files is preserved 
> since they are not modified in any way.
>
> Where this doesn't really work is with our unreleased trees: rolling 
> and release candidate.
>
> While I can trivially set $releasever to any string (see example 
> above), I'd not expect EPEL to support a '7rolling' url within its 
> infrastructure. So it seems like a 'rolling' repo may need to be 
> provided, but now we've got more repo files which puts us back into 
> the problems listed out above. This solution at least exists.
>
> Further problems come with the Release Candidate tree. If we keep our 
> SL6 conversions: yum-conf-sl7x will be installed by default and the RC 
> will be its own directory (7.1) on the ftp servers.
>
> How then do we get the release candidate to point into the RC dir 
> given that it isn't '7x' isn't '7rolling' and has yum-conf-sl7x 
> installed?
>
> I've no idea.......
>
> Pat
>


-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/