On Thu, 17 Jul 2014, Stephan Wiesand wrote:

> On Jul 16, 2014, at 21:20 , Dag Wieers wrote:
>
>> On Wed, 16 Jul 2014, Stephan Wiesand wrote:
>>
>>> But I think SL_no_colorls is flawed. Marc, did you never have the 
>>> problem that dircolors returned after a coreutils update? Moving the 
>>> files out of the way IMO should be done in "%triggerin -- coreutils" 
>>> rather than "%post" to prevent that and to make the results 
>>> independent of the installation order...
>>
>> Please consider the following advice from Red Hat:
>>
>>    https://access.redhat.com/articles/rhel-abi-compatibility
>
> Well, I had read that one. It simply doesn't apply in this context. 
> It's about packaging applications, while we're discussing system 
> configuration. And they're telling us to leave their distro packages 
> alone, which is exactly what we don't want to do in some cases:

I disagree, the advice should not be taken lightly.

RPMs are a file distribution mechanism with a set of features built-in 
(signature verification, dependencies, checksum, basic config handling, 
...). But it is mainly a file distribution mechanism.

Even if the files are tagged as configuration files, they are not intended 
to be replaced/owned by another package. In fact, that is made impossible 
by RPM itself. So whatever work-around you create is directly going 
against the design of RPM.

What's more, configuration often depends on many outside factors that RPM 
itself is not aware of, and was not designed to be aware of. Of course RPM 
itself gives plenty of opportunities to build those things into it, but it 
is band-aid nevertheless. Triggers are such band-aid when applied to 
configuration management. And I'd be surprise if you'd be the first who 
thinks the RPM macro "expansion" language is a convenient way to 
express yourself :-)

So in normal configuration management you have an inventory, and facts 
about your system(s) and these facts influence your templates that define 
a system's configuration. And these facts can change, or these templates 
can evolve, so configurations evolve as well. And you need a mechanism 
that can reapply these changes in a moving environment or for new systems.


Now let's get to some misconceptions:

> They dump a colorls.sh on us, with no knob to turn it off. Doing away 
> with it if you don't want it is the right thing to do, and
> the best way to do it is a trigger.

They don't dump it on you, they ship it as the default. But it is the 
default configuration file, and configuration files are allowed to be 
changed. Now if you would remove it, RPM will assume it was an accidental 
removal and place it back (I called this "basic config handling), however 
if you simply change it (like, make it empty) RPM will consider this a 
genuine change and will not touch it in the future !!

No triggers (or fake packages) are needed.


> They dump an avahi daemon package on us which will automatically start 
> the daemon every time a system boots once the package is
> installed. It's easy to pick up inadvertently as a dependency even if 
> you don't want it. To chkconfig it off if you don't want that
> is the right thing to do, and again the best way to do that is a 
> trigger.

We have never inadvertently installed any package, simply because we 
control what is being installed (also through a configuration management 
system) and because those are being tested. But the avahi package 
(containing the daemon) is only required by avahi-tools, and nothing 
requires avahi-tools. Most (if not all) tools that can work with avahi 
depend on the avahi-libs package that does not offer the avahi services.

If you want to avoid having the avahi package installed, simply exclude it 
using yum and it won't be installed. As a matter of fact I don't have it 
installed on my desktop system, but I do have avahi-libs installed.

No triggers (or fake packages) or needed.


So while I would make the case for a configuration management system (my 
personal preference is Ansible), none of your use-cases really require RPM 
package or triggers.

That said, if you are happy with it, by all means, don't change. But for 
anyone who was considering it, please don't wander off into the dark ;-)

-- 
-- dag wieers, [log in to unmask], http://dag.wieers.com/
-- dagit linux solutions, [log in to unmask], http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]