On Mon, Jul 13, 2026 at 06:13:20PM +0200, Helmut Grohne wrote:
> 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.
>...
Is my understanding correct that you are saying that while tmpfiles
might become part of the (transitive) essential set that is always
installed, we would still need package dependencies for ensuring
the correct order of package configuration during upgrades?
This would rule out my [A] option, since the dependency would exist
also in "no init" situations.[1]
> Helmut
cu
Adrian
[1] A dummy provider with "systemd-tmpfiles -> /usr/bin/true"
might be possible if really desirable.