Seconded. On Oct 17, Lucas Nussbaum <lu...@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
signature.asc
Description: Digital signature