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

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



Seconded.

On Oct 17, Lucas Nussbaum <lucas@debian.org> wrote:

>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

-- 
ciao,
Marco

Attachment: signature.asc
Description: Digital signature


Reply to: