Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

[Rich Freeman]

On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner <antarus@g.o> wrote:
>
> gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
> solution somewhat elegant from my side as a sysadmin.
>

I think the "right approach" depends on the degree to which the file
requires tweaking.

For 99% of users, udev requires no touching at all (though the
persistent network names drive me nuts so I touch it anyway).  If you
do touch it most likely you're just adding one rule, or overriding a
rule or two.  That makes the approach it uses of defaults and
overrides really nice, because you don't have a ton of cruft to merge
in /etc - the only code that is present is the stuff that matters.

For 99% of users, xorg.conf needs little touching at all (which is a
VERY welcome change from how it used to be).  My xorg.conf.d contains
one file with 6 lines in it.  So, the new approach makes sense.

My postfix config contains a large number of overrides, as do most.
Postfix really needs a moderate bit of setup in terms of setting
domains, policies, and so on.  Most people have anti-spam or
greylisting or such enabled, or they relay through an outside smtp
server, and so on.  Plug-and-play configs are unusual for a mail
server.  That tends to make the big file in /etc with lots of changes
more useful - it gives you a template to edit, and if upstream changes
something you want to see what it is so that you can decide how to
best merge in your tweaks.

So, the traditional approach works best for config files that need a
lot of editing which don't lend themselves to modularization.  I find
the new approach works better for situations where the files are very
modular (that is, in practice you can change just one setting and not
have to look at others), and when changes are the exception rather
than the rule (which means that you're only managing exceptions).

Personally, I'm glad my udev rules directory is now nearly empty.
Previously it was just a situation where orphan rules caused trouble,
updates required care, and so on.  Now the only things that can
possibly cause trouble are my disabling of the persistent network
names, and a few rules that add symlinks for some pl2303s so that I
can refer to them with consistent names (which I don't actually need
any longer anyway now that I use a cablecard tuner).

Rich