On Sun, 17 Sep 2023 at 02:03:52 +0200, Santiago Vila wrote:
> If the files are intended to be modified "in place" by the
> system admin, we call them configuration files (and we try hard
> to put them in /etc). If they are not intended to be modified by
> the system admin, we don't call them configuration files (and
> we try hard not to put them in /etc).
Perhaps an interesting example of this is that in packages originally
developed on an OS with less elaborate conffile handling than dpkg's
(like dbus, originally developed on/by Red Hat), there used to be a
common pattern of having:
1. a file in /etc that sysadmins are specifically asked *not* to edit,
for which non-dpkg package managers would be asked to default to
the equivalent of dpkg's "use the maintainer's version" (for example
%config in RPM), like /etc/dbus-1/system.conf
2. a separate file for local changes, which might or might not exist with
empty or template contents by default, for which non-dpkg package
managers would be asked to default to the equivalent of dpkg's "keep
the locally modified version" (for example %config(noreplace) in RPM),
like /etc/dbus-1/system-local.conf
/etc/dbus-1/system.conf was traditionally a dpkg conffile because
of its location, but it wasn't really a configuration file by
the definition Santiago gave here (and it has now been moved to
/usr/share/dbus-1/system.conf as a result): it's more like part of the
implementation of dbus-daemon --system that, as an implementation detail,
happens to have been written in the dbus-daemon XML configuration language
rather than in C.
/etc/dbus-1/system-local.conf isn't created by default, but sysadmins
can create it if they want to, and it's a "true" configuration file
(although in practice I'd recommend "drop-ins" in /etc/dbus-1/system.d
as a better version of /etc/dbus-1/system-local.conf).
smcv
