On Sun, Apr 23, 2017 at 12:16:58PM +0200, Evgeni Golov wrote:
> Ohai,
> 
> LXC recently got a bug (#860974) that is best fixed by bumping a certain
> sysctl limit above the default.
> 
> However I could not find any documented policy how to do this (if at all).
> 
> Both, procps and systemd support (/usr)?/lib/sysctl.d/*.conf, however only
> one package (systemd-coredump) uses it, all others drop files in
> /etc/sysctl.d.

The "packages drop files in /usr/*, sysadmins override in /etc" way of
doing things is prevalent in the RPM world; in Debian, however, we
traditionally have packages drop files in /etc, and let the maintainer
change them in place. This is possible, because our package management
system deals better with changed files than does RPM (which must work
silently, rather than confirming things with the user). 

The reason both procps and systemd support /usr/* files is presumably
because they're installed and shipped in both worlds, and it makes
little sense to patch software to *remove* a feature, even if we end up
not using it. However, that doesn't mean we should necessarily drop
files in /usr if we can avoid it.

There are things to be said to have the whole default configuration live
in /etc; IMO, it makes it easier for a system administrator to figure
out what the current configuration is, rather than having to mentally
merge configuration files from several locations. Additionally, when a
configuration file that had been edited by a user is now also edited by
the package maintainer, on Debian the system will ask how to handle it,
rather than changing the defaults and not telling people (which can
break in some circumstances). In contrast, on an RPM system the system
will just create the new configuration file with a .rpmnew extension,
but will have it not active.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Reply via email to