On Thu, Jul 10, 2014 at 1:31 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On Thu, Jul 10, 2014 at 12:16 PM, Sven Kieske <svenkieske at gmail.com> wrote: >>> >> On 09.07.2014 19:14, Les Mikesell wrote: >>> I've been looking for a sane way to get repeatable updates out of >>> yum forever (i.e. update production to match your last QA update >>> after testing is complete >> You really want to implement a config management solution for this. >> Pick one: >> ansible, cfengine, chef, puppet, saltstack etc. etc.. >> > > 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. And by the way, I'd not use a 'yum list'. The yum output is difficult to parse, with extraneous and difficult to predict line breaks, unnecessary headers, etc. If you've got to go this way of replicating package lists, use: rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' Or use 'rpm -qa --qf '%{name}.%{arch}\n' if you don't care about particular versions. > The problem with these is that they add an additional layer of > complexity and don't do what I specifically want done - which is to > reverse-engineer the updated package revisions after testing is > completed and repeat updates to those same package version numbers Right.... > modulo any differences in hardware related packages and some special > cases that are our own local location specific packages. Except for And this is when you suddenly need something more complex. That's where something more powerful is very useful. > saltstack, they don't seem that well designed for cross-platform > environments and even there windows seems like an afterthought - and > it seems sort of fragile the way things can break if you update > clients ahead of the server. Yeah, consistency across environments is difficult. That's where tools like spacewalk can be useful, if only it didn't require so much time and resources to set up in the first place. > -- > Les Mikesell > lesmikesell at gmail.com > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel