[CentOS-devel] Delta RPMs disabled by default?

[Les Mikesell]

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.

>
> 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.

I sort-of like yum's knowledge of repository the package came from.
I just wish it would do something sensible about comparing/duplicating
a set.   Given that the packages are version, I think there should be
a way to do the same operations you do with source version control and
for the same reasons.

>> 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.

I'd be happy if I could just say 'update' but don't take any packages
newer than 'timestamp'.  Where 'timestamp' would be the time of the
test host update.  CentOS is stable enough that I'll take my chances
with hardware specific updates that might be different, plus we never
update enough systems at once to have a problem with an unforeseen
hardware issue.

>> 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.

Don't think spacewalk is going to help with the windows boxes, and
probably not Suse either.  And aside from the complexity,  I don't
think it matches our workflow where many separate groups handle
different components on different platforms, all with their own
release scheduling.  There are probably some tools that could be made
to work, but I don't understand them well enough to see how the right
steps could be done by the right people to control the update
scheduling while ensuring that the changes are exactly what has been
tested.

So, I'd really rather have the much simpler capability of being able
to repeat a yum update with predictable results.

-- 
  Les Mikesell
      lesmikesell at gmail.com