On Fri, Jul 11, 2014 at 5:42 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote: > >> >> 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. I had a long discussion with someone else about ostree, but it all seemed to be oriented around telling it specifically what package versions to install and test before it can duplicate it for production. And I think it needed a snapshot of the packages for each state. I want something to reverse-engineer the working system and tell the others to get the same package versions from the usual places. We generally have lots of different versions of things with lots of different overlapping releases and I don't want to manage intermediate snapshot copies of entire systems or repositories in all of the possible states I might want to reproduce. It's not that it couldn't be made to work, just that it seems like all you should ever need is the list of versioned package names. Or better yet, a timestamp of the latest package version you want to update to. -- Les Mikesell lesmikesell at gmail.com