3752
Comment: OpenRC ported
|
3784
|
Deletions are marked like this. | Additions are marked like this. |
Line 21: | Line 21: |
* 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. | * Makes for healthy competition; 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. |
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 almost done already
- 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 - not advantageous as OpenRC is backward compatible
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 some Linux users who specifically want this, not just the ports.
- Allows users to keep what they have already (if at least one of the init systems is compatible with SysV init scripts); this may allow non-Debian packaged software to continue working without modifications.
- Makes for healthy competition; 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 ideal for some desktop environments or servers; and a simpler init system for embedded systems and small VMs.
- Would allow GNOME+logind+systemd+Linux to continue pursuing their goals without disrupting others.
- Allows the ports (GNU/kFreeBSD, Hurd, and others) to continue to exist (if at least one of the supported init systems is available to them). A newly-developed port would be able to target whichever is easiest to implement.
- Allows a smoother, less risky introduction of a new init system.
- Easier to backport jessie packages to wheezy, if those packages still support sysvinit.
- One of the init systems would likely use the SysV init scripts that are already there - this does not require new work (but could be an overhead for future package maintenance).
- Perhaps systemd or Upstart would continue to use some packages' SysV init scripts, meaning there is support already for multiple init system without additional work or overhead.
- 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. However:
- 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 already, from Ubuntu downstream.
- 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.