Hi! On Thu, 2026-06-18 at 08:42:45 +0200, Niels Thykier wrote: > Guillem Jover: > > Package: debhelper > > Version: 14.1 > > Severity: important
> > 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. > > 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. 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. > 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 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. On Thu, 2026-06-18 at 09:57:03 +0200, Chris Hofstaedtler wrote: > * Niels Thykier <[email protected]> [260618 08:45]: > > 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. > > [..] > > 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. 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
