On Wed, 2006-08-30 at 18:55, Jim Perrin wrote:
> > Any change can break things, even if it is intended as a bug/security
> > fix, and there are some machines where you really want someone else
> > to do the testing first. I've always thought that yum should have
> > an option to ignore anything newer than a specified timestamp just
> > to make updates repeatable across a set of machines, but it is
> > another good point that you may just want to be sure you have a few
> > days to watch for problems that others mention on the mailing list
> > before updating a critical server. I think the only way to have that
> > kind of control now is to mirror a complete copy of all the repositories
> > you use locally so they can age a bit.
>
> Very true, however anyone using 'bleeding edge' and 'critical server'
> in the same sentence needs to take a very close look at their concept
> of reality and compare it to the rest of the population. Any critical
> system should have testing done on a dev/test environment before
> production. That's admin 101 stuff however and I don't feel that it's
> appropriate for software to decide. At most I see this being a yum
> plugin for desktop/hardcore perpetual testers. My personal opinion is
> that it has no place in yum proper.
Testing isn't so much the issue as reproducing the installation
of the same set of packages you tested. In my opinion, a program
intended to help with package management should permit that easily
even if someone adds some new files to the repository after you
start testing. It's not quite impossible with yum, but its
not something I'd call handy.
--
Les Mikesell
lesmikesell@xxxxxxxxx
