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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
