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