4 ms·
FYI - here the full text of the winning proposal: https://www.debian.org/vote/2019/vote_002#textb https://www.debian.org/vote/2019/vote_002#textb Choice 2: B:
by jwildeboer 7y ago
FYI - here the full text of the winning proposal:
https://www.debian.org/vote/2019/vote_002#textb https://www.debian.org/vote/2019/vote_002#textb
Choice 2: B: Systemd but we support exploring alternatives
Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.
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.
- upofadown 7y ago>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. This part directly addresses the current issue; people were just ignoring those that were working to make non-systemd debian possible and were refusing to even talk about the issue. It will be interesting to see what happens now if those people continue to behave in the same way. So this actually ends up being a victory for the non-systemd faction, at least in a political sense.