Bug#727708: init system coupling 2nd draft CFV
Here are the options on the table right now:
L Software may not depend on a specific init system (Ian "mk2")
N No TC resolution on this question at this time (Keith)
A Advice: sysvinit compatibility in jessie and multiple init support
FD
Full texts below. I have improved the formatting of my text. Russ
intends to update his text. The summary lines are non-normative and
may be clarified.
The Call for Votes will be at 18:00 UTC tomorrow, about 23.5h from
now. Other amendments proposed (and maybe accepted) before then will
appear on the ballot.
Ian.
L Software may not depend on a specific init system (Ian "mk2")
================================================================
Rationale
The default init system decision is limited to selecting a default
initsystem for jessie. We expect that Debian will continue to
support multiple init systems for the foreseeable future; we
continue to welcome contributions of support for all init systems.
Rubric
Therefore, for jessie and later releases, we exercise our power to
set technical policy (Constitution 6.1.1):
Loose coupling
In general, software may not require a specific init system to be
pid 1. The exceptions to this are as follows:
* alternative init system implementations
* special-use packages such as managers for init systems
* cooperating groups of packages intended for use with specific init
systems
provided that these are not themselves required by other software
whose main purpose is not the operation of a specific init system.
Degraded operation with some init systems is tolerable, so long as
the degradation is no worse than what the Debian project would
consider a tolerable (non-RC) bug even if it were affecting all
users. So the lack of support for a particular init system does not
excuse a bug nor reduce its severity; but conversely, nor is a bug
more serious simply because it is an incompatibility of some software
with some init system(s).
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.
GR rider
If the project passes (before the release of jessie) by a General
Resolution, a "position statement about issues of the day", on the
subject of init systems, the views expressed in that position
statement entirely replace the substance of this TC resolution; the
TC hereby adopts any such position statement as its own decision.
Such a position statement could, for example, use these words:
The Project requests (as a position statement under s4.1.5 of the
Constitution) that the TC reconsider, and requests that the TC
would instead decide as follows:
N No TC resolution on this question at this time (Keith)
=========================================================
The TC chooses to not pass a resolution on this issue at the current time.
A Advice: sysvinit compatibility in jessie and multiple init support
=====================================================================
[ apparently-accepted amendments from <874n3ubiho.fsf@windlord.stanford.edu>
not yet incorporated here ]
The following is technical advice offered to the project by the
Technical Committee under section 6.1.5 of the constitution. It does
not constitute an override of maintainer decisions past or future:
Packages should normally support the default Linux init system. There
are some exceptional cases where lack of support for the default init
system may be appropriate, such as alternative init system
implementations, special-use packages such as managers for non-default
init systems, and cooperating groups of packages intended for use with
non-default init systems. However, package maintainers should be
aware that a requirement for a non-default init system will mean the
package will be unusable for most Debian users and should normally be
avoided.
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add
that support themselves if they're willing and capable of doing so.
In particular, package maintainers should put a high priority on
merging changes to support any init system which is the default on one
of Debian's non-Linux ports.
For the jessie release, all packages that currently support being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so. Reasonable changes to preserve or
improve sysvinit support should be accepted through the jessie
release. There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and the
package is still basically functional. All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.
The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
release. There are too many variables at this point to know what the
correct course of action will be.
Reply to: