On Tue, 20 Oct 2026 at 00:42:33 +0200, Marc Haber wrote:
I would like to write package dependencies that a certain package indicates that it won't work without systemd, most prominently that it would NOT work with sysvinit.

What feature(s) of systemd? I know systemd's detractors often say it's monolithic, but it's actually quite modular, and the down side of that is that dependent packages do need to know which parts they are depending on.

If it only needs systemd as pid 1, then yes, systemd-sysv is the closest
thing available in the apt/dpkg packaging system [1].

If it needs a working `systemd --user` (like dbus-user-session in trixie), then systemd as pid 1 is not enough, and it needs to depend on libpam-systemd. This is a stronger dependency (more constraints) than having systemd as pid 1.

If it needs higher-level/optional components like libnss-systemd, systemd-boot, systemd-container, systemd-resolved, systemd-timesyncd then those are additional things to depend on.

systemd-sysv [...] seems kind of wrong for me since it has "sysv" in the name

This is a historical artifact of how the transition from sysvinit to systemd was implemented (initially with systemd as a non-default choice that disabled but did not remove sysvinit, and then with systemd by default). The fact that the previous default init is packaged as sysvinit-core, not as sysvinit, is another artifact remaining from that transition.

If the same transition had been done today, I think we'd probably have packages named init-is-systemd and init-is-sysvinit, with the same meaning as what's currently systemd-sysv and sysvinit-core respectively.

    smcv

---

[1] It is technically possible to run systemd as pid 1 without installing systemd-sysv, and it is technically possible to boot with init=/something/that/is/not/systemd even if systemd-sysv is installed - not every dependency can be expressed in terms of apt/dpkg Depends, which fundamentally are about what's installed, not what's running. "The running kernel must be 6.18 or later" is another example of a dependency that we can't fully enforce via apt/dpkg.

Reply via email to