Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]
On Wed, Nov 11, 2015 at 10:37 AM, Marc Haber
<mh+debian-devel@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.
Reply to: