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:
>...
> > 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,
Reading my initial post in this bug again, I referred to it as
"the dependency order suggestion" but failed to present it properly.
> 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.
Generating dependencies and keeping tmpfiles out of the Essential set
implies defining which packages are prohibited from using tmpfiles,
and continuously enforcing that.
In the libselinux1 case it strikes me as reasonable that a library was
creating the directory for a socket it might be using.
As you already noticed, the next rebuild of passwd will create a
tmpfiles dependency.
If attempting to keep tmpfiles out of the Essential set, the first
question is whether passwd is part of the packages in the Essential
set that are prohibited from using tmpfiles due to the dependency
it would generate.
Telling maintainers of packages in the Essential set (like libselinux1)
that they must not use tmpfiles while dependencies of other packages
will anyway install it de facto everywhere in the future - that's a lot
of hassle without real benefits.
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.
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.
> smcv
cu
Adrian
