>
>> Suppose that packages ship sample configuration files *that exactly
>> match their defaults* (which should in general mean that everything is
>> commented out) in some standardized path under /usr/share/doc/$package/
>> (e.g. examples/etc), that makes it easy to see what path the example
>> corresponds to in /etc.
>>
>> Then, we could have a package (e.g. "etc-commented-defaults") with an
>> on-installation trigger for that location, which automatically copies
>> over the defaults to /etc if they don't already exist, updates them if
>> they match the defaults, and (ideally) has a ucf-style mechanism for the
>> case where they've been changed. That package could also provide scripts
>> for easily seeing the diffs between your configuration and all the
>> defaults.
>>
>> Users who *don't* want that behavior can remove that package, and users
>> who *do* want that behavior could install it.
>
> Isnt this basically implementing the systemd approach, where a package
> would ship default configuration in /usr/lib/package (with all defaults,
> which dont need to be commented out) and the user can override by
> putting files in /etc/package -- either by copy-and-edit or just adding
> individual changes. (I think systemd-sysctl does this, also suppporting
> /run/ for temporary changes?)
>
> I think systemd can already tell you how the locations have been merged
> together (eg 'systemctl cat' does this), but perhaps what is missing is
> a way to see what changed on upgrade (you'd want to save the clean
> version from the _previous_ version of a package to be able to do that
> after the upgrade)?
This is why there won't ever be "one policy to rule them all" for configuration
files. The issue isn't an inconsistency in the way the packages are built.
Sufficient work by packaging teams, over time, could simply set a policy and
work toward that.
The problem is that different apps interpret their configs in different ways
when a directive is encountered multiple times:
1. second instance overrides
2. first instance overrides
3. instances accumulate
4. error condition
That's just off the cuff. There are probably more cases involving
context-specific instances and so on. But this variation is necessary as each
case will follow the needs of the package.
If I were in charge of the world (which I am not), I would merge the "Splunk
approach" with some of the comments I've seen here as follows:
1) "package defaults" and/or "package templates" in /usr/share. These would be
meant as references and/or as a means to restore a package back to defaults
if/when the active configs are such a mess that the admin decides to start over.
2) "system global" in /etc/package/package.conf. This could be the "everything
commented" style, like sshd, or it could be the actual defaults like Splunk,
depending on whether the package does "overrides" or not. Splunk does
overrides. Sshd does not.
3) "site add-ins" in /etc/package/conf.d (or similar). We're all familiar with
this. I don't need to explain.
This way, all configs for $package are in /etc/package. I still think it's
reasonable to have package.conf and package.d/ in /etc, though it's kind of
annoying in a few cases. Either way, the active configs are simple to find,
but are still technically separated from the documentation/failsafe defaults in
/usr/share which acts like a sort of "vault" that isn't part of the active
config (and is thus less likely to be modified by inexperienced admins who
ignore the "DO NOT EDIT THIS FILE" warning at the tops of default global
configs).
Any package that allows ~/.config/user-overrides isn't really affected by any
of this. Those are all the user's problem, though nothing precludes a
/usr/share/package/user-orverrides example file for whatever reason that might
be useful.
What I don't think will ever be unified is the contents of that global config,
wherever it lives. Some will be "defaults all shown and active." Others will
be "defaults shown but commented." Still others will be "defaults shown but
must be edited" (NTP). I don't think there's much of a way around that, since
developers will code their packages the way they want to, and preferences about
this sort of thing are too much subject to drift over time.
(Side note: It would be handy for these styles to have names, just to speed up
conversation, assuming they don't already.)
Anyway, I don't see these variations as a weakness, but rather as a
demonstration of the flexibilty of the system. While it's certainly good to
have one or more recommended ways of doing things, there doesn't have to be One
Right Way for everything. That would be both boring and restrictive.
--J
