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'. On Thu, 23 Oct 2003, R P Herrold wrote: > I do not know that I saw a reply by Jim Wildman to the 'change > control' question, but the core concept is that a given client > host should be able to be pushed (or its yum find and pull) > only a tested, 'back-outable', and approved packageset at a > stated and known EVR. The 'ad hoc' nature of yum's dependency > solution for an 'unruly' way most OSS end users is a great > match; with 'change control' and a defined package set, it is > also possible to push out transactions (for yum to solve > against) of just 'permitted' and approved updates to update > mirrors; this also permits more policy based management of > hosts. > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@xxxxxxxxxxxxx http://www.rossberry.com