That's an interesting idea.  I don't want to forget to make the new one 
and leave people in a weird state, so I could roll it into seperate rpm 
generated by the sl-release sources.....

hmmmm......  something to think about.

Pat

On 07/07/2014 09:00 AM, Andras Horvath wrote:
> Wouldn't upgrading the yum-conf-sl7x package itself too solve the problem after the RC and before the final?
>
> Andras
>
>
> On Mon, 7 Jul 2014 08:41:18 -0500
> Pat Riehecky <[log in to unmask]> wrote:
>
>> I've gotten two suggestions on possible ideas here.
>>
>> Thanks to Mátyás and Oleg for participating in this conversation!
>>
>> Mátyás suggested possibly using 'slreleasever' to setup the repo files.
>> This would allow for a single repo set, rather than a 'rolling' and a
>> 'non-rolling' repo config.  Its an interesting idea!  I'm not sure how
>> to integrate this with the '7x' repo to allow seamless transition from
>> '7x' to '7.0' as I was considering a separate RPM to set the system to
>> '7x' rather than '7.0' - in keeping with the SL5 and SL6 traditions.
>>
>> Are there other community thoughts/suggestions/solutions on this idea?
>>
>> Oleg has suggested a symlink on the server side.  I'm not entirely sure
>> which problem set he is aiming at.  Oleg, may I request further
>> clarification?
>>
>>
>> Does anyone have any thoughts on the release candidate overlap? For SL6,
>> with duplicate repos, it was an annoying but solvable problem.  With a
>> single repo set, and with a release candidate _not_ linked to '7x' I
>> worry.  It is totally possible I'm worried over nothing.....
>>
>>
>> One of my personal aims for SL7 is to try and make this release easy to
>> manage, while keeping the historic SL flexibility.  Am I spending time
>> on something the rest of you are not worried over or would this be a
>> helpful improvement (if we can solve it)?
>>
>>
>> Again, thanks to Mátyás and Oleg for their involvement in this process!
>>
>> Pat
>>
>>
>>
>> On 07/03/2014 04:19 PM, 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
>>>
>>


-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/