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]