Simon Richter <s...@debian.org> writes: > Right, but the dependency chain is there to make sure the package is > usable on systemd systems, i.e. we'd have to accept a regression for the > systemd case in order to facilitate the non-systemd case, which is what > we don't want, or live with unrelated packages changing people's init > system, which we also don't want.
> It wouldn't be a problem in practice to break that dependency chain, as > systemd based installations tend not to be curated on a > package-by-package basis, so the packages would be installed there > anyway, but we still need a working policy. My recollection is that these dependencies are mostly about either making sure user sessions are available or that D-Bus is available, right? (I'm fairly sure about user sessions and less sure about D-Bus.) Is it possible to have a systemd system that doesn't have these properties? In other words, do these dependencies only matter with other init systems, or do they also matter in container scenarios? > Until a technical solution to find the runtime dependencies caused by > dbus service activation exists, dependencies in the systemd ecosystem > will most likely be specified manually by package maintainers, and > similar dependency chains will likely pop up more and more. I think the idea of Ian's proposal is that we're explicitly accepting not being able to represent dependencies properly in our dependency system until someone comes up with a neat technical solution. This seems basically fine to me -- it means that systems will need to install some packages to be usable and dependencies won't take care of that automatically, but that's not entirely a new problem in Debian, and while not ideal, switching people's init systems on package installation seems much worse. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
