Bug#727708: init system resolution - revised proposal
Josh Triplett writes ("Bug#727708: init system resolution - revised proposal"):
> A couple of comments inline below.
...
> 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:
This is why we use the word "software", not "packages".
> 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. ]
I agree with the intent here but I think it's best done in policy
rather than in the TC resolution.
Ian.
Reply to: