On Wed, 30 Aug 2006, Les Mikesell wrote: > 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. Reproducing an installation starts to approach a valid reason :) However build and file time stamps are not reliable way of doing this, nothing guarantees that packages arrive in a given repository in the order they are built: for example the vendor might have a heavier testing programme for the kernel than some minor package, causing kernel to arrive in the repo much later than some other package despite having an older timestamp. If you want reproducable installations, use versionlock (plugin available in yum-utils) on the packageset you tested and forget about timestamps. - Panu -
