Hi!

I was updating a chroot, and I got systemd pulled in automatically due
to the dh_installtmpfiles misc:Depends values.

The order seems wrong, because if the system already uses systemd then
the systemd dependency does not need to be first, but if the system does
not use it (or does not need any init system at all), having it first
will pull it in, which in case of chroots, that's a significant size
and dependency increase.

So the small implementations should go first, and the last one should
be systemd.

This applies as well to dh_installsysusers.

Thanks,
Guillem

Guillem Jover:

Those who cannot remember the past are condemned to repeat it. And I
forgot #1017441 - that is on me.

Since there  are virtual dependencies involved, the best I can do:

    `systemd-standalone-tmpfiles | systemd | systemd-tmpfiles`

Which means only one of the small implementations comes first anyway.


But even then, I think the main problem here is that we are trying to
express different defaults for different cases via the dependency
system. The dependency system is not built for that, so no matter what I
do, the order will be wrong for some case. Namely, we are trying to solve:

  * The `systemd` is the default implementation for any Debian bootable
    system that support `systemd`

  * We generally want `systemd-standalone-tmpfiles | systemd-tmpfiles`
    for other systems (chroots, containers, etc.)


Which means the choice must be resolved outside `debhelper`'s dependency
clause. That falls on tools like `debootstrap` and `mmdebootstrap`
(which is why I am CC'ing josch). As I recall, `mmdebootstrap` just
pulls the first option and no order can solve both cases at the same time.


I have a feeling there is no "one size fits all" here. If I use the
current order, some are unhappy and if I swap someone else will be unhappy.

This is not were I want to spend my volunteer energy, so if we conclude
there is indeed no "one size fits all" I will hand it over to the
tech-ctte to make the call.
   In my view, it would clearly fit the bill of being a technical issue
that affects multiple packages with no clear "owner" of the problem. It
would also allow me to reduce this to a regular agreed dependency - even
if it is agreed by authority rather than organically grown.


Best regards,
Niels

* Niels Thykier <niels@thykier.net> [260618 08:45]:

I think in the past it was always concluded that the orders and
defaults that get expressed in packages and control files are for
the "default installation" (whatever that is, but supposedly a
single user unix machine possibly with a graphical desktop), and
everyone else has to make local adjustments.

I don't like this, but that seems to be the general consensus.

Ideally we could tell installation-like tools what the intended
usecase of the Debian installation is, but outside of d-i I'm not
aware of anything there. Ideally this approach could be shared
between different tools, so not each and every tool has to reinvent
the wheel.

Maybe some metapackages would be a first step. They could pick/force
the tmpfiles and sysusers providers.

Chris

Hi!

I'm not sure why the virtual package is a concern when not being the
first alternative, as that's what usually trips over some tools.

I don't really see the problem here, as we already have such selection
mechanism in place. This is done via the init metapackage, which
correctly pulls in systemd-sysv as the default init system (in contrast
to just systemd). And AFAICT, whether to include or not an init system
is also already supported by the various bootstrappers, via their
"variant" support or similar.

I think there's a big difference between an init system or any other
component that is expected to be already in place for the relevant
kinds of systems (init for bootable ones), versus a random service or
specific functionality provider where we have multiple alternative
implementations but have decided on a default one. In the latter case
I agree that we should express the default via the dependency system
because if you need that service and it's not going to be already
installed something needs to select it.

But for something like an init system the default is either already
installed or if is not (because no init system makes sense here or
another one has been selected) then I don't think it makes sense to
pull one in.

And in addition this seems to be conflating what init system to default
to, with a specific tooling implementation that can be fulfilled by
systemd in particular (which is not enough to provide an init system
anyway). So this concern seems a bit weird to me.

Thanks,
Guillem