A few messages ago I was on about declarative package listsings vs defining procedures: declarative: foo-1.2.3-1 bar-1.2.3-1 procedural: install foo-1.2.3-1 install bar-1.2.3-1 .. where in one you just say what you want a machine to look like, in the other you say how you want to change a machine. Having spoken to people who could remember why this was important I've got an example: LAPTOPS! Say on day 1 you deploy an update to all the machines in your enterprise "install foo-1.2.3-2" .. then on day 2 you ship "install newthing-1.2.3-2" (never been on the machines before). .. and on day 3 you ship "install foo-1.2.3-4". .. but on day 2, 5 laptops where away in a conference with no connectivity to get your updates. When the laptops come back they get your new "install foo-1.2.3-4" command, but when do they get newthing? With a procedural (action based) approach it's really ugly to make sure every machine gets all the updates. It gets worse if you have a series of install, uninstall, install actions that a machine missed while it was disconnected. With a declarative system the laptops would just notice that they didn't have a package that they were supposed to have and install it. You don't give a damn about what happened in between. ATM I think that a combination of rpm groups and declarative listsings of what a machine should look like are likely to give the best usability characteristiscs. Does anyone else have any opinions on this? Maybe I've been brainwashed? Carwyn
