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:

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: 

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

And so on.

Yes, the safest way to achieve these things is to have cfengine, puppet or whatever carry out checks and idempotent operations every time they run. Alas, these will have to run after each and every rpm transaction, as soon as possible, and that still will result in a time window where the system is not in the desired state considerably larger than the one you can achieve with triggers. And running the full set of cfengine/puppet/... configuration can be truly expensive in terms of system resources. A trigger, on the other hand, runs just once - when and only when it makes sense.

The above is all about software missing a sane way to configure it, and there's plenty of that.

A good way to make something configurable today is to allow dropping a file somewhere in /etc/*.d . And again, using RPM to do that is just right. Just try to find out which of your puppet/... recipes dumped a certain file in /etc/frobnitz.d - and compare that effort to rpm -qf .

Please note that I'm still assuming that the set of installed packages is controlled by a configuration management system (like puppet/cfengine) or some script spawned from it. Then configuring "I want SL_no_colorls.rpm installed on this system", however you do that with the framework in question, is really universal and most obvious.

In fact, these SL_ rpms are useful to *anyone* able to control what packages are installed on a certain system, in whatever way. Hard to beat, really.

>    https://access.redhat.com/articles/rhel-abi-compatibility
> 
>    5. Package applications using the RPM mechanism. RPM provides a
>       software-packaging mechanism that includes detailed specification
>       of application dependencies. When creating RPMs, the following
>       should be kept in mind:
> 
>       (a) Avoid using RPM triggers whenever possible.
> 
>       (b) Explicitly state all required runtime and build dependencies
>           using the appropriate RPM syntax.
> 
>       (c) Do not modify, replace, or recompile files managed by Red
>           Hat-provided RPM packages. Doing so may lead to unpredictable
>           behavior.
> 
>       (d) When considering dependencies, do not assume that all possible
>           packages will be installed on every Red Hat Enterprise Linux
>           system. The default installed packages may change between major
>           releases, between product variants of the same version, and on
>           a customer’s system. For instance, the Workstation product will
>           have a different installed package set than the Server product.
> 
>       Rarely, and due to extenuating circumstances, packages might be
>       removed  between minor releases but Red Hat will provide
>       notification if this occurs.
> 
> And these guidelines cover Scientific Linux equally.
> 
> -- 
> -- 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]

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany