On Fri, May 11, 2012 at 9:25 AM, Warren Young <warren at etr-usa.com> wrote: > >> >>> There are several solutions to be able to make that happen ... manual >>> repos yourself, mrepo, spacewalk, etc. >> >> All of those that I've investigated make you manage copies of packages >> locally which seems like overkill when you aren't changing them >> locally. > > It seems to me that if you want this "stop on 6.x" feature, it's because > you certainly[*] have more than 1 box to manage, which means keeping a > local repo with local copies of the RPMs will result in faster updates, > with less impact on your Internet link. > > So it's a feature. No, its not what I what. I have multiple boxes but in different locations, all of which have good internet connectivity - better than to each other.. And the people who can verify the application level tests are not the same ones who would be managing a local repo copy so it would be much more cumbersome to mirror a repo to the same rev at all locations to freeze the contents, update a test box from it, have the testing performed, then update the production boxes from those frozen repos - and probably duplicating all that infrastructure for every application since different testing would be involved and the timing overlap would not be predictable. So far I've been fortunate that breakage from updates is very rare, so I've gotten by by just watching the list of updates that yum intends to perform for changes likely to affect anything between the tested version and the production rollout, but I'd really prefer it if yum had a way to do repeatable operations even if there are additions to the repos. Like Johnny said - he (and upstream) is in control of what yum will do - and realistically there has been more QA/testing on the code than any individual is likely to match so the possibility of breakage comes down to very specific things about your applications or hardware. Still, there is the suggestion that very controlled testing would be a good thing - but it would be even better if the tools supported it without having to roll out a vast amount of new infrastructure and administration. It seems really crazy to have to mirror an entire repository in every state that you might want to re-use just to be able to pick up updates to a minimally-installed system predictably. If you've included a few programs from EPEL (etc.), do you mirror that too? -- Les Mikesell lesmikesell at gmail.com