Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Fri, 22 Nov 2019 at 09:03:29 +0100, Ansgar wrote:
> I would like to recommend packages to use tmpfiles.d(5) to manage
> creating directories in locations such as /var or /etc instead of
> maintainer scripts.
Using tmpfiles.d(5) seems like a good thing to encourage, but using
them *instead of* maintainer scripts is less simple. My understanding
is that in current Debian policies and status, if a package relies
on tmpfiles.d(5) for important functionality and does not depend on a
tmpfiles implementation, that would usually be a grave bug.
The only tmpfiles implementation in Debian right now (that I know of) is
the combination of systemd-tmpfiles(8), systemd-tmpfiles-setup.service
(for creation of tmpfiles during boot), the maintainer script
fragments generated by dh_installsystemd (for creation of tmpfiles
during installation), and systemd as pid 1. I'm not entirely sure why
systemd doesn't have a trigger on tmpfiles.d, but perhaps it's because
the sequencing would be wrong: a package's tmpfiles generally need to be
created before its postinst reaches the point where services are started,
and I don't think triggers would guarantee that.
(<https://github.com/OpenRC/opentmpfiles> is an alternative implementation,
but is not in Debian and would require adjustments to dh_installsystemd.)
It is of course fine to ship tmpfiles.d(5) fragments (like dbus does)
as long as the package either depends on systemd as pid 1, or has some
redundant way to create enough tmpfiles that it can work without systemd
as pid 1; and I think it might be good for Policy to recommend that
required directories in /run, /var and /etc are listed in tmpfiles.d(5)
fragments, particularly /run and /var/cache.
Ways to avoid solely relying on tmpfiles.d(5) include creating
directories from maintainer scripts (possibly redundantly), shipping
directories (other than in /run!) in the .deb (possibly redundantly),
and creating directories on a just-in-time basis in init-scripts or
init-script-equivalent constructs like systemd services (possibly
redundantly).
Note that I am deliberately saying "without systemd as pid 1" rather than
"with a non-systemd init", because there is a subtle difference. If you
install (for example) dbus into a chroot or container that does not run an
init system at all, then the current dh_installsystemd fragment will see
that /run/systemd/system doesn't exist, so /usr/lib/tmpfiles.d/dbus.conf
will not be processed and /var/lib/dbus will not be created. (Reference:
look in /var/lib/dpkg/info/dbus.postinst for "Automatically added
by dh_installsystemd".) This doesn't matter for the D-Bus system
service, because the D-Bus system service will not be started in those
chroots/containers (there is no init to start it), but it does matter
for dbus-x11 (which also wants to see /var/lib/dbus/machine-id for
the autolaunching protocol) and anything else that is using the D-Bus
machine ID.
This means that even if GR 2019-002 resolves that we will stop supporting
non-systemd init systems, there will still be two cases to consider:
systemd vs. no init at all.
Another potential difficulty is that some tmpfiles.d(5) fragments might
assume that systemd is installed: certain guarantees/constraints,
such as /etc/machine-id behaving as documented in machine-id(5),
are known to be true on systems with systemd as pid 1, but not on
Debian systems in general. dbus' tmpfiles fragment creates a symlink
/var/lib/dbus/machine-id -> /etc/machine-id based on the assumption that
machine-id(5) is as documented, which is not necessarily true without
systemd (again, this can mean either sysvinit as pid 1, or no init
at all).
For some packages these issues could be solved by a dependency on
systemd (in this case not systemd-sysv the init system, just systemd
the collection of executables) and suitable adjustments to the
dh_installsystemd maintainer script fragment; or by a dependency on
systemd | opentmpfiles and suitable adjustments to dh_installsystemd,
if someone packages <https://github.com/OpenRC/opentmpfiles>.
> This has advantages over maintainer scripts
I agree, and I would like to seem more use of tmpfiles.d(5), but I think
it needs to be thought through some more.
> As far as I understand the current GR is unrelated to adopting things
> like systemd-tmpfiles.
I don't think that's true: as long as the only working implementation
of tmpfiles.d(5) in Debian requires systemd as pid 1, and Debian aims to
support pid 1 other than systemd, we can't rely on tmpfiles.d(5). Some of
the possible results of the current GR would change those constraints.
Someone packaging opentmpfiles could also change those constraints.
smcv
Reply to: