On 07/03/14 16:19, 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 I may not understand this correctly, but if you can make arbitrary variables, can't you just make an "slreleasever" and modify the .repo files accordingly? -Mat