Bug#727708: init system coupling etc.
On Wed, Feb 12, 2014 at 6:56 PM, Russ Allbery <email@example.com> wrote:
> Please note that I personally am currently leaning towards voting Keith's
> proposal above the one that I'm proposing in this message for the reasons
> that he states in that message.
Given the overall heat in the prior debate, I can see value in basic
guidance without forcing anybody's hand. As Ian notes, these are
> I'm also happy to consider amendments to this text along the lines of
> Steve's proposed language elsewhere in the thread.
I think Sam had a worthwhile idea: Avoid normative language in
preference of observative language. To quote Debian's favorite card
game: "It has been observed that..."
Under section 6.1.5 of the Debian Constitution, the Technical Committee
observes the following:
Having a default init system means that all normal packages support
it. Packages with a very specific purpose can deviate from this.
Examples include 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
Packages lacking support for the default init system may be unusable
on most Debian systems, thus limiting their adoption.
Debian tries to offer choice whenever possible. Choice can be increased
by adding or maintaining support for alternate init systems. Two
possible ways for package maintainers to achieve this goal are to
implement support themselves, or to apply patches provided to them.
It is important that platform-independent packages support all default
init systems on all Debian platforms.
Smooth upgrades from stable to stable+1 are rightfully expected by
Debian users. For upgrading from wheezy to jessie in particular,
upgrades with both the old and new default init system running need
to work. One good way to ensure smooth upgrades is to maintain and
improve sysvinit support over the jessie lifecycle.
sysvinit may not support all features of the default init system.
This could result in degraded operation of some packages. Working
around or fixing this degradation provides a benefit to Debian users.
jessie+1 is too far into the future to make useful observations about
future requirements or package dependencies on specific init systems
* I am unhappy with the tautology in the beginning; it reads very much
like "the default is the default"
* Russ' text reads generally smoother, my version is more cumbersome
* I deliberately avoided calling the default system by name, same as Russ
* You are more than welcome to use, re-use, or discard all of this; if
it's useful: good. If not, please simply ignore to keep S/N ratio high