Bug#1140305: debhelper: misc:Depends pulls systemd on chroots

[Niels Thykier]

Guillem Jover:

Package: debhelper
Version: 14.1
Severity: important

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

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.




 * 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.)










Best regards,
Niels

Those who cannot remember the past are condemned to repeat it. And I forgot #1017441 - that is on me. 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: 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.

OpenPGP_signature.asc
Description: OpenPGP digital signature