Bug#727708: Init system resolution open questions
Ian Jackson writes ("Re: Bug#727708: Init system resolution open questions"):
> As I mentioned on IRC, I think we need to get some clear answers to
> certain questions from everybody.
My answers:
> * For which init systems should there be a low nmu threshold for
> native support in packages ?
At least systemd, upstart and openrc, provided the policy guidance is
in place.
> * Daemon package maintainers should accept reasonable patches for
> some set of init systems. Which init systems ?
All.
> * What opinions do we state for jessie+1 - are we hoping for one or
> two systems (which two), or more, or are we not saying yet ?
We would like to make provision of sysvinit scripts optional. We
would like to continue to support multiple systems into the future so
long as their communities remain healthy.
Ideally there would be some kind of metalanguage or conversion or
compatibility scheme that would allow at least simple cases to be
dealt with without duplicated effort.
> * If systemd is the default on Linux, what opinions do we want to
> state, if any, re non-Linux ports at this stage ?
We should express the hope that they will use upstart and that it will
be suitably ready on both kFreeBSD and Hurd.
> * What should be an RC bug in jessie ?
Lack of support for sysvinit. Dependency on a particular init system
as pid 1.
> * What should be an RC bug in jessie+1 ?
Lack of support for whatever the default is on Linux; also, lack of
support for whatever the default is on kFreeBSD. Hopefully the Hurd
default will be the same as kFreeBSD. In both cases support via
sysvinit compatibility is acceptable to avoid the RC bug (but
obviously support only via sysvinit compatibility is not desirable).
> I also think we need to answer:
>
> * What level of dysfunction is OK if an application (or a desktop
> environment or whatever) isn't running on its preferred pid 1 ?
Interfaces or functions which access features of a particular init
system are allowed to break. Basic functionality must still work.
> * Do we want to give any guidance about what a maintainer may consider
> an unreasonable native-init-system-support patch ? Or to put it
> another way, do we intend to overrule a maintainer who declines to
> implement one (or any) non-forking startup protocol ?
A maintainer must not reject a patch solely because they don't care to
support that init system. A maintainer _may_ reject a patch because
they don't like the specific non-forking startup protocol being used.
Ian.
Reply to: