May be -- just symlink on server side?

On Fri, Jul 4, 2014 at 1:19 AM, Pat Riehecky <[log in to unmask]> 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/