On Fri, Jul 11, 2014 at 6:42 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote: > On Fri, 2014-07-11 at 14:38 -0500, Les Mikesell wrote: >> On Thu, Jul 10, 2014 at 5:46 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote: >> > >> >> >> So you are saying that the system does not have its own sane way to >> >> manage packages? >> > >> > Most do. But there are often subtle implications. The chef "java" >> > cookbook, for example, has no option to set a particular RPM release >> > number, only to select a basic java "7" or "6" major release, and to >> > select the openjdk or Oracle versions. When the original author did >> > not appreciate the desire for more granularity, it can be very >> > difficult to get the subtleties like particular Java release >> > installed as needed. >> >> But that would be exactly the thing I'd need to control - and I don't >> want to control it by having to know anything about the packages ahead >> of time. For example updating to versions between java1.7u25 and >> 1.7u55 would have broken an elasticsearch cluster. But I wouldn't >> have known that ahead of time to use any top-down control. I want to >> control it by taking a known-good instance, built/tested by some group >> that knows the details of the component they develop best, and be able >> to duplicate that system as exactly as possible (allowing for >> hardware/network/etc. differences), updating some subset of production >> boxes at a time over some timespan. Excuse me: you have completely conflicting requirements. "I want absolutely consistent control of the packages", vs. "I don't want to actually know ahead of time what they should be". One has to give. You can set up a template system (such as a kickstart installed base system, or a mock repo built chroot cage from locked repositories), and use that to *derive* your package list. But once you've done that, you "know ahead of time" what you want on the rest of the sytems, the ones that you actually want to control configuration of. So don't get caught up in that "I don't want to know ahead of time" idea, because you *have* to know at some point in order to be able to set the configurations. And as soon as you say "except for hardware/network/etc.", you need scripting and logic to localize the settings. Since configuration tools like chef, cfengine, puppet, etc., etc. all make tacit assumptions about your package management that don't have that much detail, whatever you use needs additional logic. It may as well be an RPM list, with a bit of logic around hardware drivers, piped through a shell script, because that's the computing equivalent of what you want in any more powerful configuration system.