[CentOS-devel] Delta RPMs disabled by default?

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