Vincent Danjean wrote: > Le 10/11/2015 14:49, Andrew Shadura a écrit : > > I think you can try to do it systemd way: keep the default configuration > > in /usr/lib, and leave /etc for local user configuration which overrides > > the default config. > > > > Not sure how good is this idea, I hope others can comment on this. > > For myself, I find this a very bad behavior: > - etckeeper cannot track the evolution of the config files
Don't think of them as "config files"; the files in /usr/lib or /usr/share are the system or distro defaults, not to be edited by the user. The files in /etc are your *changes* to those. I personally find that the shift to putting only changed configuration in /etc, rather than myriad "config" files full of defaults or comments, makes etckeeper far less noisy. I've wished for a long time that etckeeper could separate the base Debian defaults from my configuration as a system administrator, keeping a pristine "defaults" branch separate from the live branch with my changes in it. This approach of putting those pristine defaults into /usr and only system administrator configuration into /etc provides exactly that, just without a log of changes to those defaults. I look forward to /etc being completely *empty* except for my own configuration as the system administrator. As for versioning of changes to the defaults, I hope someday to see all package contents stored and distributed via version control, making it easy to track changes even across versions I haven't actually installed on my system. > - if I 'modify' a file by putting another one in /etc that overrides > the default one in /usr, when the default will change I won't be > notified When the compiled-in default of a program changes, you don't get notified either. When the behavior of a program in /usr/bin changes, you don't get notified either. We have changelogs and NEWS.Debian for that. And if those aren't sufficient, we could build tools to help show differences in defaults from version to version. As mentioned above, I'd love to see this problem solved by version control of package contents themselves. Personally, I've found that this change has meant far fewer dpkg conffile warnings on upgrade, and far fewer spurious conflicts. Under normal circumstances, my experience has gone from "suspend dpkg, vimdiff files in /etc, merge the upstream changes into my configuration file as always" to "just upgrade and everything works". > - when I want to look at the config of the software, I've to "merge" > two files or even two directories (one in /etc and one in /usr) systemd has tools for this; "systemd show foo" will show you the complete configuration of the foo service, including compiled-in defaults, /usr, and /etc. When you configure a piece of software, you already have to consider both the defaults and your own configuration. I would suggest that the problem here isn't moving defaults out of /etc into /usr, but rather the lack of widespread tools for managing that configuration. That's a fixable problem. - Josh Triplett