Samuel Thibault wrote: > Ansgar ๐, le jeu. 19 dรฉc. 2024 16:21:03 +0100, a ecrit: > > And it is actively harmful as if one edits the example configuration to > > have a useful configuration as dpkg will start annoying admins with > > "the example configuration has changed; what do you want to do" > > messages. > > Yes, but the thing is: I *do* want to see that message, to make sure > what changed upstream and fix my manual configuration accordingly.
There are (at least) two different models of handling configuration here; people used to one model find the other to be awkward and cause problems, and vice versa. In the model where you augment the default system configuration by adding files in /etc, you ideally don't *need* a complete copy of the configuration file. You add a file that has the single configuration directive you want to change. If the upsteam configuration changes, you automatically get the new defaults for all the other options. I've found that often, the diffs of a complete "sample" configuration file with commented-out defaults don't have changes to the defaults, they tend to have new options. That makes the diff much less useful, and much less likely to lead me to make any changes to my own configuration. However, I think there *is* a best-of-both-worlds option here. 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. That seems like an improvement over the current situation, in which there's a mix of packages that ship commented-defaults (causing problems for the people who want an empty /etc) and packages that don't (causing problems for the people who expect a sample file in /etc). It'd be a step along the road towards having a uniform policy for handling configuration files.
