seth vidal wrote: > >2. the yum-script work I've been trying to get more time to finish - in >this case it is just an xml file of actions to take. >ex: ><yum> > <transaction> > <config>/path/to/yum.conf</config> > <package action='update'>foo</package> > <package action='install'>gcc*</package> > <group action='update'>Base</group> > <group action='install'>Workstation Common</group> > </transaction> ></yum> > >That sound about right? > Sort of, there are subtle differences between this action/procedural model and a declarative model that states package versions to have on a system though. Being able to see the state of a given machine at any given point in time is simpler with a simple list declaring the state explicity rather than adding deltas. i.e. if a machine starts in state A then you apply delta <update1> then <update2> etc. These kind of considerations come into the frame when you are thinking about accountability and traceability - e.g. an ISP that want's to show that it _did_ have a security patch installed when that DDoS happened. As long as you can do things like rollback updates and uninstall software then functionally it would do most things we have found useful. Carwyn
