On Mon, Jul 13, 2026 at 06:28:59PM +0300, Adrian Bunk wrote:
> If not having tmpfiles available in some "no init" setups is desirable,
> then we do not want to have dependencies generated that would pull it in.
There are (at least) two distinct reasons to keep tmpfiles out of
essential. And when I say reasons, I don't want to say "we must keep it
out", but highlight aspects that can be weighed to form an opinion.
The obvious one is keeping essenntial small.
The other is mentioned in my other mail: You cannot just include a
package in essential. Special policy requirements apply to packages in
essential and systemd does not satisfy them, because it is known to not
work at all times in an unpacked state. Not having tmpfiles in essential
means that we can avoid figuring out how to make systemd suitable for
essential. It also means that it'll be less likely for a systemd upload
to break our build infrastructure.
The choice now becomes one of:
1. Keep tmpfiles out of essential.
2. Make it essential and ignore our experience with systemd breaking
during upgrades.
3. Make it essential and make systemd more robust.
> If we want to guarantee that everything from systemd-tmpfiles calls in
> maintainer scripts will always happen, then adding tmpfiles to the
> Essential set is the simplest solution.
>
> seedfiles+libcap2 is only 220kB, not something huge to avoid at any cost.
Having multiple providers of tmpfiles also poses a challenge to being
essential. While we also do this for awk, it is half a lie and only
works well, because awk both rarely used in maintainer scripts and
rarely switches implementations. I am pretty sure that I can craft an
upgrade scenario where awk violates policy. With multiple tmpfiles
providers and lots of users, we are way more likely to encounter the
situation where the essential functionality is not always provided. The
coreutils-from package also runs into this and uses diversions to ensure
that switching providers satisfies essential requirements.
Even though I present reasons not to make it essential, I am in favor of
promoting the tmpfiles.d mechanism as the tool of choice for the tasks
it solves.
And then, the reasons I give are all addressable with effort rather than
being fundamental limitations. Would anyone be interested in working on
making systemd more robust in upgrades or making the tmpfiles provider
switching more robust?
Again, I am voicing my own opinion and not CTTE's.
Helmut
