Before editing this page, please see the instructions on how debates work. If you are not the maintainer of a position statement, and have a suggestion or change to make, please contact the maintainer. It is too late to make changes now; the TC has already reviewed the position statements and is making its decision soon, see 727708.
Supporting multiple initsystems
Supporting two chosen initsystems for jessie would overcome a lot of issues with choosing a single replacement/default.
On mainstream ports (Linux amd64, i386) where two initsystems would be available, a package should be tested and made to work reasonably well on both. For example:
- upstart and OpenRC
- systemd and OpenRC
- upstart and sysvinit
- systemd and sysvinit
- systemd and upstart and OpenRC...
Pro multiple init systems
- Offers GNU/Linux users an alternative, if they object to the new default.
- Could offer a heavyweight init system aimed at desktop environments or servers; and a simpler init system for embedded systems and small VMs.
- Makes for healthy competition; the init systems' features, robustness and performance could be demonstrated side-by-side; popcon would measure their popularity; the BTS would collect feedback of real users' experiences.
- Allows a smoother, less risky introduction of a new init system.
- Users might work around transition or compatibility issues, particularly with custom or non-Debian packaged software, by swapping init systems.
- Easier to backport jessie packages to wheezy, if for example, packages had decided to retain SysV init scripts for the sake of OpenRC.
- An arch would be still releasable even if the default init system is unavailable.
- Keeps at least one init system available to the ports (GNU/kFreeBSD, GNU/Hurd, and some unofficial).
- Future ports could implement whichever init system is easiest.
- Avoids a committment to a Linux-exclusive software stack.
- 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.
Pro OpenRC as one of the supported init systems
- Free license (2-clause BSD), simple and extensible.
- Of the modern init systems, this is demonstrably the most portable. It was trivially ported to Debian GNU/kFreeBSD and is now working on GNU/Hurd.
- Able to use existing SysV init scripts. (Package maintainers don't have to write a OpenRC runscript if they don't want to).
Pro Upstart as one of the supported init systems
Upstart seems to have closest feature parity to OpenRC (http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems), so the feature set expected by services is likely available in both.
- Able to use existing SysV init scripts. (Package maintainers don't have to write an upstart job if they don't want to).
Pro systemd as one of the supported init systems
- Clearly some people want to have it. Linux+systemd+GNOME should be allowed to pursue this integrated design if the wish; and having an alternate supported init system (available even to GNU/Linux users) should alleviate all concerns about it.
- Able to use existing SysV init scripts. (Package maintainers don't have to write a systemd unit if they don't want to).
- systemd is the easiest way right now to provide interfaces such as logind, rather than trying to replicate the functionality in Upstart.
- An ideal situation would be for multiple init systems to share one definition:
- this is true of existing SysV init scripts, which can be used by all of the proposed init systems already; or
- if OpenRC might gain support for existing Upstart declarations;
- if OpenRC might gain support for existing systemd unit files (less likely due to systemd's larger scope);
- if a standard Debian init declaration could be agreed upon and implemented in multiple init systems;
- or if a single meta-init declaration could be compiled into native Upstart/systemd/OpenRC declarations.
- Unique features of one init system that prove useful, might be implemented by the other.
- Some maintainers spoke objections to maintaining multiple init scripts / configs. However:
- I believe people from both camps would have an interest in making packages work well on their preferred initsystem, so we should be able to collaborate, share patches. Some work has already been done by upstream or other distros.
- Most packages have SysV init scripts already, which all init systems can use.
- As a last resort, a non-essential package might set an explicit dependency on only one initsystem (similar to the situation where a package is declared 'linux-any', if porting is too difficult). This must be discouraged however, or the other initsystem becomes less useful.