> 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. That's what logs are for and specifically the rpm cron job which dumps rpm -qa to a file nightly. > As long as you can do things like rollback updates and uninstall > software then functionally it would do most things we have found useful. do you mean rpm rollbacks? Have you done them? Have they failed? the rollback feature has gotten better in recent months but not hugely so. It still has a bit of travel left to be really reliable - especially when you consider the scriptlets. So you want to make a list of what the machine should look like and have the client tool figure out what needs to happen to make that so? Is this what I'm hearing gridweaver does? It seems a pain to keep up with specific version numbers in this file though. That's one of the reasons I like just being able to say 'this package, whatever version is newest and available' -sv
