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