On Sun, 12 Jul 2026 at 18:07:34 +0300, Adrian Bunk wrote:
I am hereby asking the Technical Committee for advice and a
decision regarding dh_installtmpfiles-generated dependencies.
(I'm no longer a TC member, these replies are my opinions as a DD only)
(in Adrian's option A)
The implementation of [requiring init systems to install an
implementation of the systemd-tmpfiles virtual package] would be addition
to policy 9.3 and filing bugs against init systems.
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
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.
(2.) requires init-system support, because it's a system initialization
action: systemd does it, but as far as I'm aware, other init systems
don't (see #1139903, #1138618).
(3.) requires either a daemon or a a cron-like periodic action, which in
practice should usually be managed by a service manager (init system).
Container/chroot environments with no init can easily do (1.) and (4.),
but there's no init system to start services, daemons or cron, so (2.)
and (3.) will not usually happen.
(in Adrian's option B)
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.
Note that moving the tmpfiles.d snippet from libselinux1 to
selinux-utils made a tmpfiles implementation no longer be transitively
Essential, so perhaps making systemd-tmpfiles transitively Essential is
not actually desired at this stage. But a different Essential package
could potentially gain a tmpfiles.d snippet in future, at which point
Adrian's reasoning here would apply in full (as it did before the
libselinux change).
At the moment, passwd (Priority: Required) has a tmpfiles.d snippet, so
next time it gets rebuilt with an updated debhelper, if debhelper's
behaviour has not been changed, it will pick up a dependency on a
systemd-tmpfiles implementation. That will make a systemd-tmpfiles
implementation be part of an almost-but-not-quite-minimal Debian system
- not Essential, but part of minbase, I think?
Other very common packages like sudo, udev and openssh-server also have
tmpfiles.d snippets. sudo is perhaps particularly interesting because
it's recommended (required?) for Toolbox containers (podman-toolbox in
Debian), even though those usually don't have an init system.
One side effect of [moving SELinux's tmpfiles.d(5) snippet to
selinux-utils] is that a package from the essential set now recommends
selinux-utils and installs it on many systems without SELinux,
wasting space.
I've opened a separate libselinux1 bug report #1141939 (at wishlist
severity) querying whether this Recommends is necessary/helpful.
smcv
