[CentOS-devel] Delta RPMs disabled by default?

On Fri, Jul 11, 2014 at 6:42 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote:
> 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.

Excuse me: you have completely conflicting requirements. "I want
absolutely consistent control of the packages", vs. "I don't want to
actually know ahead of time what they should be".  One has to give.
You can set up a template system (such as a kickstart installed base
system, or a mock repo built chroot cage from locked repositories),
and use that to *derive* your package list. But once you've done that,
you "know ahead of time" what you want on the rest of the sytems, the
ones that you actually want to control configuration of.

So don't get caught up in that "I don't want to know ahead of time"
idea, because you *have* to know at some point in order to be able to
set the configurations. And as soon as you say "except for
hardware/network/etc.", you need scripting and logic to localize the
settings.

Since configuration tools like chef, cfengine, puppet, etc., etc. all
make tacit assumptions about your package management that don't have
that much detail, whatever you use needs additional logic. It may as
well be an RPM list, with a bit of logic around hardware drivers,
piped through a shell script, because that's the computing equivalent
of what you want in any more powerful configuration system.