General Resolution: Init systems and systemd

Time Line

Proposal and amendment 2019-11-16
Discussion Period: 2019-11-22
Voting Period: Saturday 2019-12-07 00:00:00 UTC Friday 2019-12-27 23:59:59 UTC
The Project Leader has varied discussion period so that the minimum discussion period ends on November 30. [mail]

Proposal F Proposer

Martin Michlmayr [[email protected]] [text of proposal]

Proposal F Seconds

  1. Michael Biebl [[email protected]] [mail]
  2. Ansgar Burchardt [[email protected]] [mail]
  3. Julien Cristau [[email protected]] [mail]
  4. Enrico Zini [[email protected]] [mail]
  5. Matthias Klumpp [[email protected]] [mail]
  6. Ana Beatriz Guerrero López [[email protected]] [mail]
  7. Russ Allbery [[email protected]] [mail]
  8. Intrigeri [[email protected]] [mail]
  9. Luca Filipozzi [[email protected]] [mail]
  10. Moritz Mühlenhoff [[email protected]] [mail]
  11. Paul Tagliamonte [[email protected]] [mail]
  12. Jordi Mallach [[email protected]] [mail]
  13. Philipp Kern [[email protected]] [mail]
  14. Holger Levsen [[email protected]] [mail]
  15. Jeremy Bicha [[email protected]] [mail]

Proposal F

Choice 1: F: Focus on systemd

This resolution is a position statement under section 4.1 (5) of the Debian constitution:

Cross-distribution standards and cooperation are important factors in the choice of core Debian technologies. It is important to recognize that the Linux ecosystem has widely adopted systemd and that the level of integration of systemd technologies in Linux systems will increase with time.

Debian is proud to support and integrate many different technologies. With everything we do, the costs and benefits need to be considered, both for users and in terms of the effects on our development community. An init system is not an isolated component, but is deeply integrated in the core layer of the system and affects many packages. We believe that the benefits of supporting multiple init systems do not outweigh the costs.

Debian can continue to provide and explore other init systems, but systemd is the only officially supported init system. Wishlist bug reports with patches can be submitted, which package maintainers should review like other bug reports with patches. As with systemd, work should be done upstream and in cooperation with other Linux and FOSS distributions where possible. The priority is on standardization without the reliance on complicated compatibility layers.

Integrating systemd more deeply into Debian will lead to a more integrated and tested system, improve standardization of Linux systems, and bring many new technologies to our users. Packages can rely upon, and are encouraged to make full use of, functionality provided by systemd. Solutions based on systemd technologies will allow for more cross-distribution cooperation. The project will work on proposals and coordinate transitions from Debian-specific solutions where appropriate.

Proposal B Proposer

Sam Hartman [[email protected]] [text of proposal] [amendment]

Proposal B Seconds

This amendment has been submitted by the current Project Leader, and thus does not require seconding

Proposal B

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.

Proposal A Proposer

Sam Hartman [[email protected]] [text of proposal] [amendment] [amendment] [amendment]

Proposal A Seconds

This amendment has been submitted by the current Project Leader, and thus does not require seconding

Proposal A

Choice 3: A: Support for multiple init systems is Important

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.

Being able to run Debian systems with init systems other than systemd continues to be something that the project values. Every package should work with pid1 != systemd, unless it was designed by upstream to work exclusively with systemd and no support for running without systemd is available. It is an important bug (although not a serious one) when packages should work without systemd but they do not. According to the NMU guidelines, developers may perform non-maintainer uploads to fix these bugs.

Software is not to be considered to be designed by upstream to work exclusively with systemd merely because upstream does not provide, and/or will not accept, an init script.

Modification of Policy to adopt systemd facilities instead of existing approaches is discouraged unless an equivalent implementation of that facility is available for other init systems.

Proposal D Proposer

Ian Jackson [[email protected]] [text of proposal] [text of amended] [text of amended] [text of amended]

Proposal D Seconds

  1. Russ Allbery [[email protected]] [mail]
  2. Sean Whitton [[email protected]] [mail]
  3. Simon Richter [[email protected]] [mail]
  4. Kyle Robbertze [[email protected]] [mail]
  5. Dmitry Bogatov [[email protected]] [mail]
  6. Jonathan McDowell [[email protected]] [mail]
  7. Matthew Vernon [[email protected]] [mail]
  8. James Clarke [[email protected]] [mail]
  9. Thomas Goirand [[email protected]] [mail]
  10. Jonathan Dowland [[email protected]] [mail]

Proposal D

Choice 4: D: Support non-systemd systems, without blocking progress

PRINCIPLES

1. We wish to continue to support multiple init systems for the foreseeable future. And we want to improve our systemd support.

2. It is primarily for the communities in each software ecosystem to maintain and develop their respective software - but with the active support of other maintainers and gatekeepers where needed.

SYSTEMD DEPENDENCIES

3. Ideally, packages should be fully functional with all init systems. This means (for example) that daemons should ship traditional init scripts, or use other mechanisms to ensure that they are started without systemd. It also means that desktop software should be installable, and ideally fully functional, without systemd.

4. So failing to support non-systemd systems, where no such support is available, is a bug. But it is not a release-critical bug. Whether the requirement for systemd is recorded as a formal bug in the Debian bug system, when no patches are available, is up to the maintainer.

5. When a package has reduced functionality without systemd, this should not generally be documented as a (direct or indirect) Depends or Recommends on systemd-sysv. This is because with such dependencies, installing such a package can attempt to switch the init system, which is not what the user wanted. For example, a daemon with only a systemd unit file script should still be installable on a non-systemd system, since it could be started manually.

One consequence of this is that on non-systemd systems it may be possible to install software which will not work, or not work properly, because of an undeclared dependency on systemd. This is unfortunate but trying to switch the user's init system is worse. We hope that better technical approaches can be developed to address this.

6. We recognise that some maintainers find init scripts a burden and we hope that the community is able to find ways to make it easier to add support for non-default init systems. Discussions about the design of such systems should be friendly and cooperative, and if suitable arrangements are developed they should be supported in the usual ways within Debian.

CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED

7. Failing to support non-systemd systems when such support is available, or offered in the form of patches (or packages), should be treated as a release critical bug. For example: init scripts must not be deleted merely because a systemd unit is provided instead; patches which contribute support for other init systems (with no substantial effect on systemd installations) should be filed as bugs with severity “serious”.

This is intended to provide a lightweight but effective path to ensuring that reasonable support can be provided to Debian users, even where the maintainer's priorities lie elsewhere. (Invoking the Technical Committee about individual patches is not sensible.)

If the patches are themselves RC-buggy (in the opinion of, initially, the maintainer, and ultimately the Release Team) then of course the bug report should be downgraded or closed.

8. Maintainers of systemd components, or other gatekeepers (including other maintainers and the release team) sometimes have to evaluate technical contributions intended to support non-systemd users. The acceptability to users of non-default init systems, of quality risks of such contributions, is a matter for the maintainers of non-default init systems and the surrounding community. But such contributions should not impose nontrivial risks on users of the default configuration (systemd with Recommends installed).

NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES

9. systemd provides a variety of facilities besides daemon startup. For example, creating system users or temporary directories. Current Debian approaches are often based on debhelper scripts.

In general more declarative approaches are better. Where

the facility should be documented in Debian Policy (by textual incorporation, not by reference to an external document). The transition should be smooth for all users. The non-systemd community should be given at least 6 months, preferably at least 12 months, to develop their implementation. (The same goes for any future enhancements.)

If policy consensus cannot be reached on such a facility, the Technical Committee should decide based on the project's wishes as expressed in this GR.

BEING EXCELLENT TO EACH OTHER

10. In general, maintainers of competing software, including maintainers of the various competing init systems, should be accommodating to each others' needs. This includes the needs and convenience of users of reasonable non-default configurations.

11. Negative general comments about software and their communities, including both about systemd itself and about non-systemd init systems, are strongly discouraged. Neither messages expressing general dislike of systemd, nor predictions of the demise of non-systemd systems, are appropriate for Debian communication fora; likewise references to bugs which are not relevant to the topic at hand.

Communications on Debian fora on these matters should all be encouraging and pleasant, even when discussing technical problems. We ask that communication fora owners strictly enforce this.

12. We respectfully ask all Debian contributors including maintainers, Policy Editors, the Release Team, the Technical Committee, and the Project Leader, to pursue these goals and principles in their work, and embed them into documents etc. as appropriate. (This resolution is a position statement under s4.1(5).)

Proposal H Proposer

Ian Jackson [[email protected]] [text of proposal]

Proposal H Seconds

  1. Jonas Smedegaard [[email protected]] [mail]
  2. Holger Levsen [[email protected]] [mail]
  3. Michael Lustfield [[email protected]] [mail]
  4. Guilhem Moulin [[email protected]] [mail]
  5. Matthew Vernon [[email protected]] [mail]
  6. Kyle Robbertze [[email protected]] [mail]
  7. gregor herrmann [[email protected]] [mail]
  8. Sean Whitton [[email protected]] [mail]

Proposal H

Choice 5: H: Support portability, without blocking progress

PRINCIPLES

1. The Debian project reaffirms its commitment to be the glue that binds and integrates different software that provides similar or equivalent functionality, with their various users, be them humans or other software, which is one of the core defining traits of a distribution.

2. We consider portability to different hardware platforms and software stacks an important aspect of the work we do as a distribution, which makes software architecturally better, more robust and more future-proof.

3. We acknowledge that different upstream projects have different views on software development, use cases, portability and technology in general. And that users of these projects weight tradeoffs differently, and have at the same time different and valid requirements and/or needs fulfilled by these diverse views.

4. Following our historic tradition, we will welcome the integration of these diverse technologies which might sometimes have conflicting world-views, to allow them to coexist in harmony within our distribution, by reconciling these conflicts via technical means, as long as there are people willing to put in the effort.

5. This enables us to keep serving a wide range of usages of our distribution (some of which might be even unforeseen by us). From servers, to desktops or deeply embedded; from general purpose to very specifically tailored usages. Be those projects hardware related or software based, libraries, daemons, entire desktop environments, or other parts of the software stack.

SYSTEMD DEPENDENCIES

6. Ideally, packages should be fully functional with all init systems. This means (for example) that daemons should ship traditional init scripts, or use other mechanisms to ensure that they are started without systemd. It also means that desktop software should be installable, and ideally fully functional, without systemd.

7. So failing to support non-systemd systems, where no such support is available, is a bug. But it is not a release-critical bug. Whether the requirement for systemd is recorded as a formal bug in the Debian bug system, when no patches are available, is up to the maintainer.

8. When a package has reduced functionality without systemd, this should not generally be documented as a (direct or indirect) Depends or Recommends on systemd-sysv. This is because with such dependencies, installing such a package can attempt to switch the init system, which is not what the user wanted. For example, a daemon with only a systemd unit file script should still be installable on a non-systemd system, since it could be started manually.

One consequence of this is that on non-systemd systems it may be possible to install software which will not work, or not work properly, because of an undeclared dependency on systemd. This is unfortunate but trying to switch the user's init system is worse. We hope that better technical approaches can be developed to address this.

9. We recognise that some maintainers find init scripts a burden and we hope that the community is able to find ways to make it easier to add support for non-default init systems. Discussions about the design of such systems should be friendly and cooperative, and if suitable arrangements are developed they should be supported in the usual ways within Debian.

CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED

10. Failing to support non-systemd systems when such support is available, or offered in the form of patches (or packages), should be treated as a release critical bug. For example: init scripts must not be deleted merely because a systemd unit is provided instead; patches which contribute support for other init systems (with no substantial effect on systemd installations) should be filed as bugs with severity “serious”.

This is intended to provide a lightweight but effective path to ensuring that reasonable support can be provided to Debian users, even where the maintainer's priorities lie elsewhere. (Invoking the Technical Committee about individual patches is not sensible.)

If the patches are themselves RC-buggy (in the opinion of, initially, the maintainer, and ultimately the Release Team) then of course the bug report should be downgraded or closed.

11. Maintainers of systemd components, or other gatekeepers (including other maintainers and the release team) sometimes have to evaluate technical contributions intended to support non-systemd users. The acceptability to users of non-default init systems, of quality risks of such contributions, is a matter for the maintainers of non-default init systems and the surrounding community. But such contributions should not impose nontrivial risks on users of the default configuration (systemd with Recommends installed).

NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES

12. systemd provides a variety of facilities besides daemon startup. For example, creating system users or temporary directories. Current Debian approaches are often based on debhelper scripts.

In general more declarative approaches are better. Where

the facility should be documented in Debian Policy (by textual incorporation, not by reference to an external document). The transition should be smooth for all users. The non-systemd community should be given at least 6 months, preferably at least 12 months, to develop their implementation. (The same goes for any future enhancements.)

If policy consensus cannot be reached on such a facility, the Technical Committee should decide based on the project's wishes as expressed in this GR.

BEING EXCELLENT TO EACH OTHER

13. In general, maintainers of competing software, including maintainers of the various competing init systems, should be accommodating to each others' needs. This includes the needs and convenience of users of reasonable non-default configurations.

14. Negative general comments about software and their communities, including both about systemd itself and about non-systemd init systems, are strongly discouraged. Neither messages expressing general dislike of systemd, nor predictions of the demise of non-systemd systems, are appropriate for Debian communication fora; likewise references to bugs which are not relevant to the topic at hand.

Communications on Debian fora on these matters should all be encouraging and pleasant, even when discussing technical problems. We ask that communication fora owners strictly enforce this.

15. We respectfully ask all Debian contributors including maintainers, Policy Editors, the Release Team, the Technical Committee, and the Project Leader, to pursue these goals and principles in their work, and embed them into documents etc. as appropriate. (This resolution is a position statement under s4.1(5).)

Proposal E Proposer

Dmitry Bogatov [[email protected]] [text of latest proposal]

Proposal E Seconds

  1. Ian Jackson [[email protected]] [mail]
  2. Matthew Vernon [[email protected]] [mail]
  3. Jonathan Carter [[email protected]] [mail]
  4. Kyle Robbertze [[email protected]] [mail]
  5. Axel Beckert [[email protected]] [mail]
  6. Brian Gupta [[email protected]] [mail]
  7. Simon Richter [[email protected]] [mail]

Proposal E

Choice 6: E: Support for multiple init systems is Required

Being able to run Debian systems with init systems other than systemd continues to be of value to the project. Every package MUST work with pid1 != systemd, unless it was designed by upstream to work exclusively with systemd and no support for running without systemd is available.

Software is not to be considered to be designed by upstream to work exclusively with systemd merely because upstream does not provide, and/or will not accept, an init script.

Proposal G Proposer

Guillem Jover [[email protected]] [text of proposal]

Proposal G Seconds

  1. Simon Richter [[email protected]] [mail]
  2. gregor herrmann [[email protected]] [mail]
  3. Jonas Smedegaard [[email protected]] [mail]
  4. Guilhem Moulin [[email protected]] [mail]
  5. Ricardo Mones [[email protected]] [mail]
  6. Mathias Behrle [[email protected]] [mail]
  7. Steve Kostecke [[email protected]] [mail]
  8. Alberto Gonzalez Iniesta [[email protected]] [mail]
  9. Kyle Robbertze [[email protected]] [mail]
  10. Adam Borowski [[email protected]] [mail]
  11. Donald Scott Kitterman [[email protected]] [mail]

Proposal G

Choice 7: G: Support portability and multiple implementations

Principles

The Debian project reaffirms its commitment to be the glue that binds and integrates different software that provides similar or equivalent functionality, with their various users, be them humans or other software, which is one of the core defining traits of a distribution.

We consider portability to different hardware platforms and software stacks an important aspect of the work we do as a distribution, which makes software architecturally better, more robust and more future-proof.

We acknowledge that different upstream projects have different views on software development, use cases, portability and technology in general. And that users of these projects weight trade-offs differently, and have at the same time different and valid requirements and/or needs fulfilled by these diverse views.

Following our historic tradition, we will welcome the integration of these diverse technologies which might sometimes have conflicting world-views, to allow them to coexist in harmony within our distribution, by reconciling these conflicts via technical means, as long as there are people willing to put in the effort.

This enables us to keep serving a wide range of usages of our distribution (some of which might be even unforeseen by us). From servers, to desktops or deeply embedded; from general purpose to very specifically tailored usages. Be those projects hardware related or software based, libraries, daemons, entire desktop environments, or other parts of the software stack.

Guidance

In the same way Debian maintainers are somewhat constrained by the decisions and direction emerging from their respective upstreams, the Debian distribution is also somewhat constrained by its volunteer based nature, which has as another of its core defining traits, not willing to impose work obligations to its members, while at the same time being limited by its members bounded interests, motivation, energy and time.

Because of these previous constraints, trying to provide guidance in a very detailed way to apply the aforementioned principles, is never going to be satisfactory, as it will end up being inexorably a rigid and non-exhaustive list of directives that cannot possibly ever cover most scenarios, which can perpetuate possible current tensions.

These will always keep involving case by case trade-offs between what changes or requests upstreams might or might not accept, or the upkeep on the imposed deltas or implementations the Debian members might need to carry on. Which can never be quantified and listed in a generic and universal way.

We will also keep in mind that what might be considered important for someone, might at the same time be considered niche or an uninteresting diversion of time for someone else, but that we might end up being on either side of the fence when sending or receiving these requests.

We will be guided, as we have been in many other Debian contexts in the past, by taking all the above into account, and discussing and evaluating each situation, and respecting and valuing that we all have different interests and motivations. That is in our general interest to try to work things out with others, to compromise, to reach solutions or find alternatives that might be satisfactory enough for the various parties involved, to create an environment where we will collectively try to reciprocate. And in the end and in most cases it's perhaps a matter of just being willing to try.

Proposal C Proposer

Sam Hartman [[email protected]] [text of proposal] [amendment] [withdrawal]

Proposal C Seconds

This amendment has been submitted by the current Project Leader, and thus does not require seconding
  1. Ansgar Burchardt [[email protected]] [mail]

Proposal C

Focus on systemd for init system and other facilities (withdrawn)

Quorum

With the current list of voting developers, we have: 

 Current Developer Count = 1011
 Q ( sqrt(#devel) / 2 ) = 15.8981130955846
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 47.6943392867539

Quorum

Data and Statistics

For this GR, like always, statistics will be gathered about ballots received and acknowledgements sent periodically during the voting period. Additionally, the list of voters will be recorded. Also, the tally sheet will also be made available to be viewed.

Majority Requirement

The proposals need a simple majority

Majority

Outcome

Graphical rendering of the results

In the graph above, any pink colored nodes imply that the option did not pass majority, the Blue is the winner. The Octagon is used for the options that did not beat the default.

In the following table, tally[row x][col y] represents the votes that option x received over option y. A more detailed explanation of the beat matrix may help in understanding the table. For understanding the Condorcet method, the Wikipedia entry is fairly informative.

The Beat Matrix
 Option
  1 2 3 4 5 6 7 8
Option 1   185 246 223 227 278 243 307
Option 2 207   243 211 216 286 240 299
Option 3 159 131   113 120 250 165 225
Option 4 192 177 235   137 309 261 281
Option 5 187 168 222 163   301 246 271
Option 6 116 104 88 53 51   121 173
Option 7 168 145 176 93 91 207   216
Option 8 110 111 166 114 124 214 168  

Looking at row 2, column 1, B: Systemd but we support exploring alternatives
received 207 votes over F: Focus on systemd

Looking at row 1, column 2, F: Focus on systemd
received 185 votes over B: Systemd but we support exploring alternatives.

Pair-wise defeats

The Schwartz Set contains

The winners

Debian uses the Condorcet method for voting. Simplistically, plain Condorcets method can be stated like so :
Consider all possible two-way races between candidates. The Condorcet winner, if there is one, is the one candidate who can beat each other candidate in a two-way race with that candidate. The problem is that in complex elections, there may well be a circular relationship in which A beats B, B beats C, and C beats A. Most of the variations on Condorcet use various means of resolving the tie. See Cloneproof Schwartz Sequential Dropping for details. Debian's variation is spelled out in the constitution, specifically, A.6.

Debian Project Secretary