Philipp Kern writes ("Re: Bug#727708: TC resolution revised draft"):
> On 2014-01-30 15:47, Ian Jackson wrote:
> > == optional rider M (Multiple init systems) ==
> >
> > Debian intends to support multiple init systems, for the
> > foreseeable future, and so long as their respective communities
> > and code remain healthy.
> >
> > Where feasible, software should interoperate with non-default
> > 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.
>
> So if we assume that upstart wins, would it be acceptable to depend on
> systemd (or vice versa)? We might then get a set called, say, Unity,
> depending on upstart and one called, say, GNOME, depending on systemd,
> which would not be co-installable. Maybe there should be a paragraph
> addressing this?
So, my previous version of this rider was this:
Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code remain healthy.
(Same as above.)
Software outside of an init system's implementation may not
require a specific init system to be pid 1, although degraded
operation is tolerable.
Different to above. Perhaps adding this:
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.
would soften this text.
I will ensure that something like this gets onto the ballot iff I hear
from the project that they think it's important to vote on it in the
TC (even if the TC seems likely to reject it).
I'm obviously open to suggested wording improvements for the version M
you see above (which is in the git repo) and this stronger
compatibility requirement version.
Ian.