Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
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
Reply to: