On Wed, Nov 11, 2015 at 10:37 AM, Marc Haber <mh+debian-de...@zugschlus.de> wrote: > > 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.
If systemd-delta could be enhanced to apply to one unit (its current output can only be limited to a specific unit type), it could be integrated into the installation of packages providing systemd units. systemd isn't the first package to allow/promote shipping distro settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev and polkit/policykit have behaved like this for a long time. There's also "/usr/lib/sysctl.d/" where a distro ship settings that can be overridden via "/etc/sysctl.d/". I don't know how extensively it's used on Debian - it's empty on my systems - but systemd used to modify, at least, kernel.sysrq in older systemd versions in this way.
