Bug#727708: init system resolution - revised proposal
A couple of comments inline below.
Ian Jackson wrote:
> == dependencies rider version T (Tight coupling) ==
>
> This decision is limited to selecting a default initsystem; we
> continue to welcome contributions of support for all init systems.
>
> Software may require a specific init system to be pid 1.
>
> However, where feasible, software should interoperate with
> all init systems; maintainers are encouraged to accept
> technically sound patches to enable interoperation, even if it
> results in degraded operation while running under the init system
> the patch enables interoperation with.
>
> == dependencies rider version L (Loose coupling) ==
>
> This decision is limited to selecting a default initsystem; we
> continue to welcome contributions of support for all init systems.
>
> Software outside of an init system's implementation may not require
> a specific init system to be pid 1, although degraded operation is
> tolerable.
There is an issue with this wording, which I don't think is intended.
Sometimes, the easiest way to maintain support for multiple init systems
involves having a family of packages, each of which enables support for
one init system or family of init systems. For instance, consider a
gnome-session-systemd package which uses systemd user sessions, provided
in parallel with a compatibility package that does not. Or, consider
the systemd-shim package. As written, this clause would prohibit such
alternative packages, even though *collectively* the packages satisfy
this requirement. I would suggest adding language like the following,
optionally with the following [non-binding] example:
Packages which form part of a set of alternatives integrating with
different init systems need not individually run on other init
systems, as long as the packages collectively meet the requirements
of this section. [ For example, a package using systemd to launch a
user session, provided as an alternative to a package that runs on
sysvinit, need not itself run on sysvinit. ]
- Josh Triplett
Reply to: