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. Hello, So I haven't fully followed the thread and thus may not be helping. However I think what you are looking for is called ostree. I have never personally used it but I think it fills the niche you are looking for which is a broad set of testable updates. No idea of the pros/cons but may be what you want to look at. -- Nathanael