Differences between revisions 11 and 12
Revision 11 as of 2013-10-29 15:51:39
Size: 3128
Comment:
Revision 12 as of 2013-10-29 20:19:14
Size: 3204
Comment:
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * Offers (most) users with choice, e.g. being able to remove systemd, if they object to it and don't need its functionality.  * Offers (most) users with choice, e.g. being able to remove systemd, if they object to it and don't need its functionality -- this benefits Linux users who specifically want this, not just the ports.

multiple initsystems

  • Anyone may contribute to this page for now, in the hope of attracting the most ideas possible.

Supporting two specific initsystems for jessie would overcome a lot of current issues with deciding on a new default. On mainstream ports (Linux amd64, i386) where two initsystems are available, a package should be tested and made to work reasonably well on both. For example:

  • systemd and sysvinit
  • systemd and OpenRC (subject to being ported)
  • sysvinit and upstart (subject to finding solution for GNOME logind)

Some combinations would be infeasible however:

  • systemd and upstart - leaves nothing for non-Linux ports
  • sysvinit and OpenRC - mostly overlapping functionality with the least benefit?

Pro

  • Offers (most) users with choice, e.g. being able to remove systemd, if they object to it and don't need its functionality -- this benefits Linux users who specifically want this, not just the ports.
  • Allows users to keep what they have already (if sysvinit is chosen as one of the supported options), and may allow non-Debian packaged software to continue working.
  • Easier to backport jessie packages to wheezy, if the packages still support sysvinit.
  • Allows for a smoother, less risky introduction of a new initsystem.
  • Having two interchangeable init systems would demonstrate the features, robustness, performance of each in practice, and be able to evaluate them; popcon would measure their popularity, the BTS would give insight into real users' experiences.
  • Could offer a heavyweight init system for some desktop environments or servers; and a simpler init system for embedded systems and small VMs.
  • Might allow GNOME+logind+systemd+Linux to continue pursuing their goals without disrupting others.
  • Allows ports (GNU/kFreeBSD, Hurd, and others) to continue their work, if at least one of the chosen init systems is available to them; a newly-developed port is able to target whichever is easiest to implement.
  • Seems fitting with Debian philosophy of a Universal OS. Is similar to how GNOME, KDE and other desktop environments have been able to co-exist in the same distribution.

Contra

  • Some maintainers spoke objections to maintaining multiple init scripts / configs.
    • I believe people from both camps have an interest in helping packages work well on their preferred initsystem, so we should be able to collaborate.
    • The problem is reduced if at least one initsystem can reliably invoke the other's (perhaps already existing) initscripts.
      • It is impossible for systemd and upstart to run each other's units/jobs, but they both can run LSB SysV init scripts; OpenRC can also.
    • Automatic generation of systemd unit files from initscripts is being worked on.
    • Some packages will have upstart job definitions, from Ubuntu downstream.
    • As a last resort, a non-essential package might set an explicit dependency on only one initsystem (similar to how a package is declared 'linux-any', if porting is too difficult). This must be discouraged however, or the other initsystem becomes less useful.