Hi Adrian and Simon and others, thank you (plural) for adding all the context. Much appreciated.
On Sun, Jul 12, 2026 at 06:45:39PM +0100, Simon McVittie wrote: > It's probably useful to note that there's more than one part to "tmpfiles > might not be functional", Having an implementation of tmpfiles.d(5) does two > potentially important things, plus two nice-to-haves: > > 1. immediately after installing a package with tmpfiles.d snippets that > ask for files to be created, the files they describe are created for > the rest of this boot (or for the rest of this chroot/container session) > > 2. after a subsequent reboot, the files configured to be created are > re-created if necessary, which is important if they are on a tmpfs > like /run I think there is yet another use that we should be considering separately. Some packages use tmpfiles.d as an alternative to dpkg-statoverride where the package installs a file using normal ownership and permission and then a tmpfiles.d snippet changes ownership and/or permissions. This is meant to be applied immediately after installing (like case 1), but it extends beyond boot or container session. This is not widely used yet (and this use may be questionable), but a notabble case is openssh: https://sources.debian.org/src/openssh/1%3A10.4p1-1/debian/openssh-client.tmpfiles | x /tmp/ssh-* | z /usr/bin/ssh-agent 2755 root _ssh > 3. (nice to have) if the tmpfiles.d snippet asks for it, the files they > describe are cleaned up when their configured lifetime expires > > 4. (nice to have) if the tmpfiles.d snippet asks for it, the files they > describe are cleaned up when the package is purged > (dh compat >= 14 only) > > (1.) and (4.) are done by maintainer scripts. If debhelper stops generating > a hard dependency and starts guarding the systemd-tmpfiles calls with a > check for availability, then instead they'll be done *conditionally* by > maintainer scripts. This would be bad for the openssh use case. Also note that a dependency does not help during package purging. Unless tmpfiles become essential, purging has to remain conditional. If I try to take a more distant point of view, I generally perceive much of this as a non-issue so long as there is an init system, because we have come to expect that an init system provides this infrastructure (sysusers.d, tmpfiles.d at boot and periodic, availability of commands during maintainer scripts). Due to opensysusers and seedfiles, we this extends even to hurd. The difficult questions arise when we look at chroots and containers. As Adrian pointed out, this is not new. The question of what we may expect from containers surfaces every now and then and different runtimes pose varying answers. We do expect availability of basic device files. Most workloads expect a working /proc and some subset of /sys. Some container runtimes support forwarding logs to the system journal. sysusers integration is not a feature container runtimes appear to have looked into. I also have't seen much effort at making hermetic /usr work on containers. The expectation rather seems to be that users have been created at the time the image is constructed. Availability of systemd-sysusers may still be useful if additional packages are to be installed. A dependency probably is appropriate here. tmpfiles integration is less obvious, because application container runtimes (and I count sbuild/schroot/mmdebstrap as runtimes) are expected to provide some of init's functionality such as mounting /run. So my initial feeling here is that we should look more closely at popular container runtimes and see what form of sysusers/tmpfiles integration they provide. Whatever they choose will be a subset of what a full init system (including non-systemd) provides and we will likely expand our custom container runtimes (e.g. sbuild) to match. The other question I have is what technical downsides we'd face if reversing the dependency and putting the standalone variants first. Generally, when systemd already is installed nothing will change. I agree that not putting our default init system first feels odd, but my question is about the practical implications of putting the standalone thing first. So long as we ensure that no transitively essential package uses tmpfiles.d (and that still seems possible), it might work well enough. Helmut
