[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: Init system resolution open questions



Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> As I mentioned on IRC, I think we need to get some clear answers to
> certain questions from everybody.

> * For which init systems should there be a low nmu threshold for
>   native support in packages ?

I believe this should be the Linux default plus (if different) whatever
init system is used by the non-Linux ports.  (Putting aside the question
of whether the Technical Committee can set an NMU threshold for the
moment.)

> * Daemon package maintainers should accept reasonable patches for
>   some set of init systems.  Which init systems ?

The same as the list for a low NMU threshold above.

> * 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 ?

I think we should say that native (not via legacy sysvinit shell scripts)
support for the Linux default is encouraged for jessie+1, and beyond that
leave this alone.

My fallback position would be to say that we expect to converge on at most
two well-supported init systems, one for Linux ports and one for non-Linux
ports.  I think the question of whether to use OpenRC or upstart for
non-Linux ports is best deferred.

> * If systemd is the default on Linux, what opinions do we want to
>   state, if any, re non-Linux ports at this stage ?

We will require sysvinit support through the jessie release.

Post jessie, my preference would be to say that support for the init
system used by non-Linux ports should be treated the same way as any other
porting issue to the non-Linux ports, such as PATH_MAX issues with Hurd.
In other words, those are normal bugs in packages unless the release team
decides that a non-Linux port is a release architecture, maintainers
should apply patches unless they're excessively intrusive, and maintainers
aren't expected to test on those architectures.

> * What should be an RC bug in jessie ?

> * What should be an RC bug in jessie+1 ?

I think we should (and possibly are required to) defer to the release team
on RC bugs in particular, but I do think we should say that support for
the default init system and for sysvinit are required for jessie (with the
caveat about what "required" means for packages that rely on functionality
not provided by sysvinit).

> 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 ?

I think this depends a lot on whether the package is something significant
enough that we would consider it to be a release blocker or whether it is
an edge package, and whether the package is directly related to the init
system or is unrelated.

For example, were someone to want to package a variety of neat daemon
management tools for OpenRC, I don't see any reason why that should be
prohibited from the archive even if it requires OpenRC to run.  And while
I think it's a little weird to have some application in the archive that's
packaged so that it will only work with a non-default init, as long as it
declares that dependency in some reasonable way (that doesn't result in
the system being switched to that init system when it's installed), I have
a hard time seeing exactly what it *hurts* to have it in the archive.

I think that major packages that would be considered release blockers,
which probably includes GNOME, KDE, and Xfce, need to support the default
Linux init system in the sense that, if they don't, I don't think we can
release.

I think a substantial degredation of functionality when running on an init
system other than the Linux default would be okay for for jessie+1.  For
jessie, I think it depends greatly on how feasible making them work with
sysvinit is (and I suspect sysvinit support would be sufficient for all
other purposes).

> * 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 ?

This is hard.  I'm not sure.  I'm leaning towards not getting into this.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: