+1 Debian has been doing a really good job at managing configuration files for years (dpkg, ucf). It gives the sysadmin complete visibility on changes and flexibility in actions. This is one strong key point of Debian versus most other distribs. Please don't change that. On 11/11/15 10:37, Marc Haber wrote: > On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett > <josh@joshtriplett.org> wrote: >> 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 violently disagree. We have always done it the other way, and had > the advantage that our conffile handling (which used to be and IMO > still is far superior to everything else other distributions have) > could notice if _both_ local changes and distribution changes happened > and ask the use what to do in this case. > > Adopting the systemd way here deprives our users of this advantage, > reducing Debian's operation safety. > > Just imagine Tom Smith having copied /lib/systemd/foo.service to > /etc/systemd/foo.service, and changed the /etc copy to better fit his > needs. Debian later finds that a bug in /lib/systemd/foo introduces a > security hole and ships a new version of that file. Tom installs the > security update, feels safe but isn't since noone warned him that the > security fix is not even looked at by his systems since his local copy > of the (old, insecure) file in /etc overrides the fix. > > Jane Jones, being smarter than her colleague Tom, uses the > /etc/systemd/foo.service.d approach to add her local changes. If we > ship a security update to /lib/systemd/foo.service, it depends on our > change whether Jane gets either the fix, or her local addition > overrides the fix as it was the case with Tom, or she gets > "interesting" local breakage due to a security update if our change > does not fit her change since she now inadvertently gets a mixture of > her and our changes. > > In my humble opinion, it is really bad if a package _this_ central and > important to Debian deviates from the Debian way this severely. It is, > IMO, a very good example about how badly systemd integrates in the > Debian ecosystem and that it was a bad decision to blindly follow how > systemd upstream handles configuration. The packaging should instead > follow how _Debian_ handles configuration. This is Debian in the first > place. > > But unfortunately the decision, bad as it is, has been taken, and > changing it at this time is not realistic. > >> 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. > > That does not happen too often, thankfully. > >> 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. > > We _DO_ have such a tool. In fact, we do have _two_ such tools. dpkg > and ucf. Why would we need a third? > >> Personally, I've found that this change has meant far fewer dpkg >> conffile warnings on upgrade, and far fewer spurious conflicts. > > We do not have systemd for long enough to see the fallout of this bad > setup. > >> 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. > > Why do we cause problems in the first place so that we _have_ to fix > them later? > > Greetings > Marc > -- Mat <mat@parad0x.org>
Attachment:
signature.asc
Description: OpenPGP digital signature