On Mon, Jul 13, 2026 at 02:49:39PM +0100, Simon McVittie wrote:
> 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 bet that you mentioned this elsewhere. This distinction into
persistent (when not considering hermetic-/usr) and ephemeral could also
be embodied into dependencies. We could have one dependency for having
the command line utility and another for the tmpfiles boot/periodic
services. Parsing the files could tell them apart. Not sure this is
actually needed.
> > 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.").
Given the state of discussion, I am pretty sure that a virtual package
(that has been proposed elsewhere already) is the way to go. The
generated dependency should likely become "default-systemd-tmpfiles |
systemd-tmpfiles" and then we can argue about which package should
provide the default at will and even change it retroactively if our
choice turns out to be bad.
> 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.
I still hope that we can get away keeping tmpfiles out of essential
while having it in the required set (aka debootstrap variant minbase).
Let me raise an argument against making it essential. Essential packages
must work at all times in an unpacked state. It is known that packages
that link libsystemd0 (e.g. systemd) do not always work during upgrades.
While systemd-standalone-tmpfiles could fill the essential spot, systemd
providing systemd-tmpfiles could not. If we wanted to get there, systemd
would have to turn multiple versions of libsystemd0 coinstallable and
basically bump the private version on every upgrade. This idea is not
new either. I've seen it mentioned at least by Michael Biebl.
Opinions stated here and in my earlier mail on this thread are my own
and not CTTE advice.
Helmut
