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