On Fri, Oct 17, 2014 at 09:44:16AM +0200, 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 I would like to see the above clause modified like this: "There may be some loss of functionality under sysvinit if the package is still basically functional." Rationale: I don't think that "the maintainer believes the loss of functionality is acceptable" is a good test for whether the cost is worth the benefit. Rather, that test should be about "how hard is it for a maintainer to support the alternative init system". If a maintainer thinks that, say, a power manager written to read /sys/power directly but control things through systemd is useless without the ability to suspend the system, they might well remove all support for non-systemd systems; if someone else believes otherwise and sends in a patch, under the proposed language the maintainer would be able to reject such patches. As such, in the spirit of §2.1.1 of the consitution, I would therefore like to see something along the lines of "in the absense of patches, it's okay for a maintainer to remove support for non-default init systems if they have no desire to maintain that support themselves, but maintainers should not reject patches implementing such support without a sound technical reason". This will allow Debian to support non-default init systems if someone steps forward and does the work, but should not stand in the way of people who just don't care and don't want to see their work doubled (or tripled, or quadrupled, or ...) by alternative init systems. > 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. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Attachment:
signature.asc
Description: Digital signature