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
