On Fri, May 11, 2012 at 9:25 AM, Warren Young <warren@xxxxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
