Sam Hartman wrote: > Apropos of the discussion about removing default configuration from > /etc. > Upstream PAM now supports doing that. You can set up a vendor directory > such as /usr/lib where pam.d and security live. > > I thought about doing that for Debian PAM, and have decided against. > My rationale is that I actually think dpkg gives superior handling of > upstream configuration changes to what we'd get with the pam vendor dir > *in the specific case of PAM*. > > In particular, dpkg will let you know if the conf file has changed > upstream and you have local changes. > If we create a vendor directory, you will have to diff yourself to > discover that. > > I do think that in the case of programs like systemd that do a complex > merge of drop in fragments, the split of vendor dir from sysadmin dir > makes a lot of sense. [...] > I think we might be able to find dpkg-based solutions that are superior.
If we're talking about developing a solution that doesn't already exist, why not have that solution *be* the notification-and-diff/show-the-defaults mechanism you're describing? For instance, provide a declarative mechanism to say "this file/directory in /usr is the default version of this configuration file in /etc", with standard schemes like 'merge' or 'override'", and then offer a tool (similar to the existing systemd-delta but generalized) to show all the configuration files that differ, as well as automatic support for flagging changes on upgrades and suggesting a three-way merge (similar to ucf)? With some care for convention-over-configuration, debhelper could auto-populate this declarative data in many cases. One advantage of this scheme is that everyone *can* get the behavior they want, with configuration in a single place. We could easily have a system-wide setting for whether you want all the defaults copied to /etc so you can edit them in-place, versus never installing any of the defaults files and leaving /etc sparse until you populate it. And it'd be easy and safe to toggle between the two. (This is similar to the systemd "vendor preset" mechanism, but again, generalized.) We can, of course, have an epic argument about which should be the *default* behavior, but hopefully the ability for everyone to get the behavior they prefer would make that a little less *vigorous* than usual. On top of that, people could extend this with other mechanisms. For instance, it'd be feasible to integrate that with something like etckeeper, making all the base configuration files into an "upstream" git branch that needs merging into your system's etc, and letting people use the full power of git merging and three-way diffs to resolve issues. Something like this would be a lot more ideal than a Debian-specific mechanism that only supports one scheme (sparse-/etc versus prepopulated-/etc). And it'd be more ideal than the current state that varies from package-to-package, where people who prefer sparse-/etc are frustrated with packages that keep defaults in /etc, and people who prefer prepopulated-/etc are frustrated with packages that keep defaults only in /usr and leave /etc empty. Perhaps we could get consensus around the idea that people want the ability to make this choice, and packages should integrate with such a mechanism rather than choosing on a package-by-package basis? - Josh Triplett
