Debian Developers Decide On Init System Diversity: "Proposal B" Wins
The Debian developer voting over init system diversity options has wrapped up and a decision has been made.
In recent months there has been lots of differing views over how much Debian should care about systemd alternatives some five years after they decided to move to systemd in the first place. Many in the Debian camp support Debian-without-systemd as an option but not all developers and those fixing bugs care about bugs that don't affect systemd, leading to this EOY2019 voting...
Receiving the most votes was Proposal B, which is "Systemd but we support exploring alternatives."
The Proposal B comes down to:
This comes up short for those that desired Debian to simply focus on systemd or at the opposite end requiring support for multiple init systems.
The general resolution voting results can be found here.
In recent months there has been lots of differing views over how much Debian should care about systemd alternatives some five years after they decided to move to systemd in the first place. Many in the Debian camp support Debian-without-systemd as an option but not all developers and those fixing bugs care about bugs that don't affect systemd, leading to this EOY2019 voting...
Receiving the most votes was Proposal B, which is "Systemd but we support exploring alternatives."
The Proposal B comes down to:
"The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative."
This comes up short for those that desired Debian to simply focus on systemd or at the opposite end requiring support for multiple init systems.
The general resolution voting results can be found here.
105 Comments