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

Alternative proposal: support for alternative init systems is desirable but not mandatory



Hi,

It is now clear that we will have a vote on this issue. I think that we
should use this opportunity to clarify the Project's position, and that's
not something that would be achieved if "Further Discussion" were to
win.

I am therefore bringing forward an alternative proposal, deeply inspired
from the "Advice: sysvinit compatibility in jessie and multiple init
support" option of the TC resolution on init system coupling[1], which
was originally written by Russ Allbery[2] and was then amended by many
participants to the discussion in February 2014.

[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
[2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html

------------------------- begin proposal ------------------------->8
Debian has decided (via the technical committee) to change its default
init system for the next release. The technical committee decided not to
decide about the question of "coupling" i.e. whether other packages in
Debian may depend on a particular init system.  However, the technical
committee stated in #746715 that "[it] expects maintainers to continue to
support the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing support
without a compelling reason."

The Debian Project states that:

   Software should support as many architectures as reasonably possible,
   and it should normally support the default init system on all
   architectures for which it is built.  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 software 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 software that currently supports 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, but Debian's standard
   requirement to support smooth upgrades from wheezy to jessie still
   applies, even when the system is booted with sysvinit.

The Debian Project makes no statement at this time on sysvinit support
beyond the jessie release.


This resolution is a Position Statement about Issues of the Day
(Constitution 4.1.5), triggering the General Resolution override clause
in the TC's resolution of the 11th of February.

The TC's decision on the default init system for Linux in jessie stands
undisturbed.

However, the TC resolution is altered to add the additional text above.
-------------------------- end proposal -------------------------->8

Lucas

Attachment: signature.asc
Description: Digital signature


Reply to: