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/