On Mon, 13 Jul 2026 at 12:20:16 +0200, Helmut Grohne wrote:
On Sun, Jul 12, 2026 at 06:45:39PM +0100, Simon McVittie wrote:
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)
This splits into two: the created files might be created on a filesystem
that we expect will persist between boots or chroot/container sessions
(like /etc, /var), or one that we expect probably won't persist (like
/run, /tmp).
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.
I think we can treat that as similar to the case where files are created
on a filesystem that persists: in both cases, we expect that after a
reboot or a container restart, the state change will persist. So we
don't need an init system, as long as the maintainer script has ensured
that the state change really happened.
(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.
Indeed, and for any other case where the state-change encapsulated in
tmpfiles.d is functionally necessary.
Also note that a dependency
does not help during package purging. Unless tmpfiles become essential,
purging has to remain conditional.
Yes, like most things that happen during purge, but this is already the
case (reference:
/usr/share/debhelper/autoscripts/postrm-init-tmpfiles-purge).
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.
Yes, and this is what Guillem suggested on #1140305. Adrian didn't
present that as an option when opening this bug, but I think it's worth
considering, even if it ends up being rejected for the reasons he gave
("It does not make sense to generate dependencies in a gazillion
packages and argue about dependency order when the end result is anyway
that we are adding a (virtual) package to the essential set.").
I'm not so sure that we really *are* adding -tmpfiles to the
transitively Essential set, and if we are not, then that makes Adrian's
reasoning less compelling.
smcv
