Bug#727708: init system coupling etc.

[Richard Hartmann <richih.mailinglist@gmail.com>]

On Wed, Feb 12, 2014 at 6:56 PM, Russ Allbery <rra@debian.org> 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
exceptional times.


> 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
  init systems.
  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
  today.


Notes:
* 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


Thanks,
Richard