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/