On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner <anta...@gentoo.org> 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
