On Fri, 2003-10-24 at 20:47, Jim Wildman wrote: > Russ got this pretty close. Once a machine is turned over to the > production support people, any change to the software (such as > upgrades) must be documented and approved by a change review board, > which includes all the parties who may be 'cross impacted' by the > failure of a particular machine. (Exceptions are made for fixing > 'failures'.) The specific changes are then approved > for a specific time frame. If the change fails, then you do a post > mortum and do it all over. So we can't let yum resolve dependenicies on > the fly on the production machines. Since we can't use it to just > transfer packages without installing them, we will use other mechanisms > to transfer a predefined list of packages, which will then be installed > during the time window. We also employ an enterprise scheduling package > which will be used to schedule the actual install/upgrade. A > missing dependency would be a 'failure'. so let me make sure I understand what this entails: you need to run yum with a '--what would you do if' parameter - and if it say what things it would need to do to update. Is that right? I was looking at the yum download-only patches and the one thing I don't like is they all seem like overkill. What if there was a more-simple yum download-only mechanism? What if it were a second, optional, y/n check AFTER the packages were downloaded. So: in default mode nothing changes. maybe you add a -n (like was suggested by Miguel earlier today) that is, essentially an additional check. yum update download headers, etc computes dependencies ask you if it's ok to do stuff downloads and gpg checks packages asks you again. If it was done that way it's: 1. a trivial amount of code 2. not just a download-only mechanism but an easy way for people to be MORE careful about installs. It seems like that would get you the set of things you need, or at least part of them. Thoughts? -sv
