[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

On 10/17/2014 03:44 AM, Lucas Nussbaum wrote:
> 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

My understanding is that Lucas clarified "currently" to mean "in wheezy".

I second this proposal.

Thanks for writing it up, Lucas.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: