Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
Simon Richter <sjr@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: