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
