On Fri, 2019-11-22 at 12:07 +0000, Simon McVittie wrote: > 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.
Sure, I don't see a problem with that in principle though? > 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 fairly sure that systemd-tmpfiles doesn't require systemd as pid-1 (though one GR option seems to imply systemd-tmpfiles and -sysusers are somehow facilities that need alternative implementations for other inits, but I don't think that claim was verified). Both -tmpfiles and -sysusers seem to work for example in Docker containers which don't run systemd-init. > 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. I think the maintainer scripts would currently need to call systemd- tmpfiles once, yes. (The same would be true for -sysusers; see also the --replace option in systemd-sysusers(8).) > (<https://github.com/OpenRC/opentmpfiles> is an alternative implementation, > but is not in Debian and would require adjustments to dh_installsystemd.) I know it exists, but I don't think we need an alternative implementation? It would be useful for non-Linux, but if people don't want to package it then we could also just recommend using tmpfiles.d(5) on Linux only. On Linux I see no advantage of having multiple implementations. People are of course free to replace them locally if they want though, just like they can for coreutils. > 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. We don't have to use dh_installsystemd and I think it was proposed to use a different helper for tmpfiles anyway (for other reasons). > (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. Sure, I'm quite interested in supporting the no-init case (I think the request to make the `init` package non-essential and optional came from me ;-)). I wouldn't be surprised if other distributions also care about that, even when they only support systemd as init. (It might even be useful to move helpers like -tmpfiles and -sysusers to a separate packages so container images won't pull in the full systemd package.) "Other inits" are probably not much different han "no init", except that they should call systemd-tmpfiles at some appropriate time during boot. > 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). I think it is fine to blacklist specific cases such as using the machine-id (at least without an explicit dependency). I don't expect many packages to use these anyway. Same for the options related to (btrfs) subvolumes and some others. > > 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). As I said above: things like -tmpfiles and -sysusers (or udev) should work fine without systemd as pid-1. I don't see any reason why they would need to require systemd as pid-1 in the future either. Ansgar