Bug#727708: multiple init systems - formal resolution proposal
Steve Langasek <firstname.lastname@example.org> writes:
> Where would this ballot option rank vis-à-vis FD, for those TC members who
> are opposed to the "loose coupling" option?
> == dependencies rider version S (split-the-init) ==
> This decision is limited to selecting a default initsystem; we
> continue to welcome contributions of support for all init systems.
> Software outside of an init system's implementation may not require a
> specific init system to be pid 1, although degraded operation is
> tolerable. Software not part of an init system's implementation may
> require interfaces unrelated to service management that are provided as
> part of an init system, but the dependency on such interfaces must be
> declared in a way that allows the dependency to be satisfied by
> compatible implementations on other init systems.
> Maintainers are encouraged to accept technically sound patches
> to enable improved interoperation with various init systems.
This continues to lock all package maintainers into providing startup
configuration for all init systems indefinitely, and therefore to me is
basically equivalent to L.
If you limited the "may not require a specific init system" part to only
jessie, I would vote it above FD, unless there's some problem with it
that's not immediately apparent to me. (I would still find L with that
modification problematic, although less so than then current L.)
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>