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/