Bug#727708: loose ends for init system decision
Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
> I think there is one additional questions that will probably need to be
> decided by the tc but hasn't really been discussed yet:
>
> Will packages that explicity depend on a (non-default) init system be
> allowed in Debian?
My answer to this is "no".
So, firstly, I would say that all packages must, in jessie at least,
continue to support sysvinit. Russ (from the other side of the
upstart/systemd fence) agrees. Failure to support sysvinit would be
an RC bug.
And since all the proposed replacement inits have a compatibility
mode, that naturally means they'll work.
Contributors who support the non-default new init system will be able
to supply patches for native support and should have them accepted.
> If such packages will not be allowed in the archive, does the burden of
> making them work with the default init lie on the maintainers of the
> default init (to add the missing feature), or the package maintainer (to
> work around the features absence if he wants the package in Debian)?
The latter.
> The specific situation that I have in mind is of course when upstart
> becomes the default, and gnome becomes dependent on systemd, but I think
> the question is larger than just this example.
Such a decision by Gnome (implying ditching all non-Linux
architectures, too) would be very disappointing IMO. I think this is
a bridge we should cross if and when we come to it.
Ian.
Reply to: