On Thu, 18 Jun 2026 08:42:45 +0200 Niels Thykier <[email protected]> wrote:
Guillem Jover:
> I was updating a chroot, and I got systemd pulled in automatically due
> to the dh_installtmpfiles misc:Depends values.
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.
Debian's dependency system is indeed too weak to express most
interesting and useful combinations of packages in non-standard setups.
Because Debian's dependency system is unlikely to change soon, anybody
who does something "non standard" will have to specify their additional
needs to the tool they use to build (and update) systems.
(For the sake of discussion, let's define "standard" = "what debootstrap
does without extra configuration".)
For example, if mmdebstrap is used to create init-less container images
(a possible and useful, but non-standard, kind of system) then the user
really should specify `--include=init-` or `--include=init-,systemd-` to
make their needs explicit, rather than hoping that the dependency chain
that happens to be calculated by apt that day will not include systemd.
One could argue (but I'm not sure if I'm ready to take this position)
that by making adjustments to the stated dependency order we are not
really helping users, just papering over issues that they will need to
address one day or another (i.e., they need to tell their tools what
non-standard configuration they really want).
Regards,
--
Gioele Barabucci
