Debian init systems GR - voting guide

Introduction

If you don't know what's going on, you may wish to read my summary and briefing blog post from a few weeks ago. There are 7 options on the ballot, plus Further Discussion (FD). With this posting I'm trying to help voting Debian Members (Debian Developers) cast their votes.

I am going to be neutral about the technical merits of systemd. My advice does not depend on your opinion about that.

So my advice here is addressed to people who like systemd and want to keep running it, and developing with it, as well as, of course, people who prefer not to use systemd. I'm even addressing readers who think systemd has useful features which they would like Debian packages to be able to use.

However, I am going to be opinionated about one key question: My baseline is that Debian must welcome code contributions to support running without systemd, just as it welcomes code contributions for other non-default setups. If you agree with that principle, then this posting is for you. Unfortunately this principle is controversial. Several of the options on the current GR mean rejecting contributions of non-systemd support. So in that sense I am not neutral.

tl;dr

(Using # to indicate the "Choice" numbers on the ballot.)

Rank H (#5), D (#4) and E (#6) ahead of all other options unless you can't accept the "portability" principles in H (#5), or can't accept the MUST in E (#6). For more on D vs E vs H, see below.

Do not be fooled by A (#3) which sounds like it actually answers the question, with a compromise. But making these bugs "important" does not have any practical effect. It just sets us up for more arguments. A also enables continuation of blocking behaviours by maintainers who want to support only systemd - probably more than G (#7) does. Both A and G are poor in their practical effect, but I would rank G ahead of A, unless you really disagree with the Principles in G.

Summary of the options

Ordered from strongest support for contributors of non-systemd support, and users who don't want to use systemd, to weakest. H (#5) is the Principles part of G (#7) pasted onto the front of the specific decisions in D (#4) - the similar-looking texts are identical.

#6	E	Dmitry	Packages MUST work on non-systemd systems
#5	H	Ian	Portability and multiple implementations, "without blocking progress"
#4	D	Ian	Compromise, "Support non-systemd systems, without blocking progress"
#7	G	Guillem	Portability and multiple implementations, avoids giving any guidance on specifics.
Options below here will mean that systemd becomes effectively mandatory for most users and developers
#3	A	Sam	Vaguely positive words, but maintainers can (and some will) block non-systemd support. Fudge, not compromise. Sets us up for more arguments.
#2	B	Sam	Encourages adoption of systemd features
#1	F	Michael	Support only systemd, encourages tighter systemd integration

Voting flowchart

You should probably vote H (#5), D (#4) and E (#6) ahead of all the other options, in some order or other For more details, and the exceptions, read on.

Q1 - Non-systemd support mandatory ?

Do you think support for non-systemd systems should be mandatory - ie that maintainers of leaf packages should be required to write init scripts, etc ?

Yes, maintainers should do the work to support non-systemd init systems.

Rank: E > H+D. (# 6 > 5+4. )

No, the non-systemd commmunity should do this work.

Rank: H+D > E. (# 5+4 > 6. )
How far down you put E depends how strongly you feel about this. I have assumed in the rest of this posting that you think the principle that the non-systemd community should be allowed to do this work is more important than the principle that other people shouldn't be required to do it. If you don't agree, you should rank E (#6) lower than the suggestions I make in the rest of this post.

Q2 - Discussion closure

How much do you care that we settle this matter once and for all? (compared to valuing accepting contributions, and thereby enabling variety in software, flexibility, portability, Debian's centrality, and so on)

Accepting contributions is more important. I expect the non-systemd community to keep using, supporting (and working on) non-systemd regardless, even if Debian makes it difficult, and in a downstream if necessary.

Rank: H+D+E > G > A > FD > B > F. (# 5+4+6 > 7 > 3 > 8 > 2 > 1. )

I want closure somewhat. If we have support in principle, I am prepared to have to revisit some of the details in another GR and/or escalate individual bugs to the Technical Committee (TC). Otherwise we should just make systemd mandatory and be done with it.

Rank: H+D+E > G > A > F > B > FD. (# 5+4+6 > 7 > 3 > 1 > 2 > 8. )

I want closure very much. I want this settled once and for all. (But I would rather have one more GR than a bunch of TC fights over individual bugs.)

Rank: H+D+E > F > FD > B > G > A. (# 5+4+6 > 1 > 8 > 2 > 7 > 3. )

NB the Rank listings here here are subject to Q3, regarding G (#7), and Q1, regarding E (#6).

You may be surprised that I suggest ranking G (#7) ahead of A (#3) even if you very much want closure, despite G's lack of any detailed guidance. This is because I think both A and G would lead to many arguments about details, but G provides clearer principles for resolving those arguments - so there would be fewer of them and they will be less bad. A also leaves much more open the possibility of a renewed attempt to desupport non-systemd systems via another GR. You may very well disagree with me on this, in which case you will want to rank A ahead of G; however I would still advise against ranking A highly.

Q3 - "Glue", portability and multiple implementations

Do you agree with the Principles at the top of proposals G (#7) and H (#5) ? Do you see the init systems debate as part of a pattern and think this is something the project needs to make a more general statement about ?

I like this vision for Debian as the universal operating system.

Rank: H > D. (# 5 > 4. )

I have concerns about making such a strong general statement, or this is a distraction which unnecessarily broadens the debate; but I can live with it if the practical results are right for init systems.

Rank: D > H. (# 4 > 5. )
Probably keep G (#7) ahead of A (#3). If you want the arguments to be over, both are poor.

I disagree with this vision and do not want it as part of the winning option.

Rank: D > H. (# 4 > 5. )
You may wish to demote H (#5) and G (#7) below other options, perhaps even below FD or A (#3). I would caution against demoting H (#5), too far, because several of those other options answer the specific init systems question badly or not at all. Consider whether you can live with this rather woolly vision text if it means the init systems arguments are ended satisfactorily.

Voting table

	Q1: Maintainers must support non-systemd		Q1: Non-systemd community should do the work
"portability" vision	I like it	I have concerns	I like it	I have concerns
Q2: Must accept contribs	E H D G A FD B F Choice 6 5 4 7 3 8 2 1 Ballot 8 7 5 3 2 1 4 6	E D H* G* A FD B F Choice 6 4 5* 7* 3 8 2 1 Ballot 8 7 5 2 3 1 4 6	H D E G A FD B F Choice 5 4 6 7 3 8 2 1 Ballot 8 7 5 2 1 3 4 6	D H* E G* A FD B F Choice 4 5* 6 7* 3 8 2 1 Ballot 8 7 5 1 2 3 4 6
Q2: Want closure somewhat	E H D G A F B FD Choice 6 5 4 7 3 1 2 8 Ballot 6 7 5 3 2 1 4 8	E D H* G* A F B FD Choice 6 4 5* 7* 3 1 2 8 Ballot 6 7 5 2 3 1 4 8	H D E G A F B FD Choice 5 4 6 7 3 1 2 8 Ballot 6 7 5 2 1 3 4 8	D H* E G* A F B FD Choice 4 5* 6 7* 3 1 2 8 Ballot 6 7 5 1 2 3 4 8
Q2: Want closure very much	E H D F FD B G A Choice 6 5 4 1 8 2 7 3 Ballot 4 6 8 3 2 1 7 5	E D H* F FD B G A Choice 6 4 5* 1 8 2 7 3 Ballot 4 6 8 2 3 1 7 5	H D E F FD B G A Choice 5 4 6 1 8 2 7 3 Ballot 4 6 8 2 1 3 7 5	D H* E F FD B G A Choice 4 5* 6 1 8 2 7 3 Ballot 4 6 8 1 2 3 7 5

* If you really dislike the Principles in G (#7), you may wish to rank it, and maybe H (#5), lower. See also my comments in Q1 about the MUST in E (#6).

In the table Choice is the Choice numbers from the vote page in the same order as the letters, ie in descending order of preference. Ballot is the preference numbers to fill in on the ballot, in the order on the ballot paper. This is confusing because of the ballot paper's reuse of numbers to mean both choices and preferences. I suggest instead that you reorder the ballot paper, as I suggest in my other blog post about ballot paper format.

Edited 2019-12-09 17:38 UTC to add Ballot number listings, discussion of ballot ordering, and link to followup post. And again at 17:40 to fix the link.

Detailed analysis of the options

I have dealt with this by theme, rather than going through the options one by one.

Overall framing and vision

E (#6)

Supporting non-systemd init systems is simply and clearly required. No wider philosophical points.

H (#5)

Strong general principles about Debian's central "glue" role, combined with detailed rules of engagement for stopping dysfunctional blocking behaviours. (Operative text is from D; principles are from G.)

D (#4)

Contributions of work, both to support non-systemd systems, and systemd, should be welcomed, but init system communites must do their own work. Detailed rules of engagement for stopping dysfunctional blocking behaviours.

G (#7)

Strong general principles about Debian's central "glue" role, support for portability, and so on. Deliberately avoids giving specific guidance; instead has some extremely vague words about being respectful.

A,B (#3,2)

Hard to discern a clear vision.

F (#1)

Claims that systemd is for "cross-distro collaboration". What this means is mainly collaboration on desktop operating systems with RPM-based distros, notably Red Hat. But it will actually hinder or prevent collaboration with (for example) GNU Guix, embedded operating systems, non-Linux operating systems such as FreeBSD, and even other distros like Gentoo or our own downstreams like Devuan. So the sense of "cross-distro collaboration" meant here is much narrower than it seems.

Clarity, vision and consequences

E (#6)

Admirably clear and straightforward. Non-systemd systems will be properly supported; some strong systemd supporters may go to work elsewhere. No wider implications.

H (#5)

Addresses specific situations relating to init systems in detail. If it is followed, the atmosphere should improve. Additionally, I find the clarity of vision attractive. Adopting it may preempt or help settle other disputes.

D (#4)

Addresses specific situations in detail (and thus rather long). If it is followed, the atmosphere should improve and we can get on with programming.

G (#7)

Clear statement of principles, undermined by an explicit refusal to give specific guidance; instead there is some extremely vague text about being respectful and compromising. In practice if this wins we are likely to continue to have a lot of individual fights over details. Despite the strong words in favour of portability etc., some maintainers are still likely to engage in blocking behaviours which will have to be referred to the TC.

Another GR is a possibility. At least, G winning now would make it look unlikely that that 2nd GR would completely de-support non-systemd, so that 2nd GR will hopefully be on a narrower question and less fraught: it will have to give the answers to details that G lacks.

A (#3)

Looks like it supports working with different init systems. It also looks like it gives specific answers. It declares that systemd-only is an "important" bug, and discusses NMUs. But NMUs are only permitted "according to the NMU guidelines" - which means that maintainers can block them simply by saying they don't like the patch. The only escalation route for an "important" bug where the maintainer does not want to take the patch is the TC. TC disputes are generally very unpleasant, especially if (as in this case) the decision involves a conflict between the interests of different communities, and the underlying principles are in dispute.

Unlike G (#7), there is no statement of broader principles that would discourage a maintainer from blocking in this way (and would narrow a TC debate by de-legitimising the kinds of very weak arguments often presented to justify these blocking behaviours). The result will be a continuation of the existing situation where some maintainers are deleting init scripts and/or rejecting patches to support non-systemd. So there will be further fights over details, probably more even than with G (#7).

I would expect another GR at some point; that 2nd GR would probably involve a renewed attempt to de-support non-systemd systems. So I think this provides even less of a clear decision than G.

B,F (#2,1)

In the short term, Debian contributors and users who don't like systemd may switch to Devuan instead (or simply shrug their shoulders and reduce their engagement). In the medium to longer term, Debian's narrowing of focus will make it less attractive for its current variety of interesting use cases. Debian's unwillingness to let people within Debian forge their own path will make it less fun.

Are init scripts required and who must write them?

Actually, init scripts are really just an example. All of the proposals treat other kinds of leaf package support for non-systemd init systems in a roughly similar way.

E (#6)

init scripts are mandatory. Maintainers must write them.

H,D (#5,4)

Maintainers do not have to write them, but they must accept them if they are provided (and they must not simply delete them from existing packages, as some have been doing). Ie, the non-systemd community must write them if it wants them where they are currently missing.

G (#7)

No guidance. We might hope that the strong words on portabilility and multiple implementations will cause constructive behaviours by the various contributors, but in practice escalation of some kind, or a further GR, will be needed.

A,B,F (#3,2,1)

Maintainers do not have to write them and do not need to accept them.

What about systemd sysusers.d, timer units, etc.

Consider for example, sysusers.d: this is a facility for creating needed system users - an alternative to our current approach of debhelper script fragments containing adduser calls. Or consider timer units, which overlap with cron. These do not necessarily imply actually running systemd; other implementations would be possible. Some people think some of these facilities are better and are unhappy that progress in Debian (particularly in Policy) has been blocked in this area.

Note that although this has been regarded by some people as being blocked by systemd sceptics, in fact it's mostly that the proponents of these facilities have not wanted to write a 2nd implementation for non-systemd systems.

E (#6)

Such facilities may only be used if there is an implementation for non-systemd systems. Effectively, this means proponents of such a facility must do the reimplementation work. But if they do, adoption of these facilities is unblocked.

H,D (#5,4)

There is a list of criteria for whether such a facility may be adopted, including feasibility of implementation for non-systemd (and non-Linux) systems, and whether the facility is any good. If a facility is approved then the non-systemd community get time (probably in practice 6 months) to reimplement the facility for their init system(s). In case of dispute the TC is to adjudicate the listed criteria.

G (#7)

No specific guidance. Formal adoption of these facilities in Policy is likely to remain blocked but uncontrolled adoption in individual packages is a real possibility.

A,B,F (#3,2,1)

Package maintainers are free to adopt these facilities in an uncoordinated way, making their packages work only with systemd. Presumably systemd Depends or Recommends would follow.

Dependencies which force (or switch) the init system

Some packages which would work fine without systemd cannot be installed, because the dependencies are overly strict. (This because of difficulties expressing the true situation in our dependency system, and what I see as largely theoretical concerns that systemd systems might come to miss parts of the systemd infrastructure.)

E,H,D (#6,5,4)

Dependencies on systemd are forbidden (E) or dependencies are not allowed to try to switch the init system (H,D). Effectively, this means that this situation is forbidden.

G (#7)

No specific guidance. This will lead to further arguments, unfortunately, since this situation is contrary to the Principles in the resolution but not clearly discussed.

A,B,F (#3,2,1)

These dependencies are to be tolerated. Core package maintainers can maintain strict dependencies even if they make running without systemd difficult or impossible.

Acknowledgements

Thanks to everyone who helped review this posting. Thanks also to the Debian Members who proposed and seconded of the options on the ballot. Everyone who helped draft, or seconded, any one of these options has helped make sure that we have a good slate of choices.

I would like particularly to thank: Russ Allbery for his review comments on my option D which substantially improved it, and his encouragement (all remaining deficiencies are of course mine); Sean Whitton and Matthew Vernon whose support and friendship have been invaluable; Guillem Jover for having an excellent vision and then being very constructive and tolerant about the way I appropriated his language; Dmitry Bogatov for providing a very clear and simple proposal and engaging with the process well; and I even want to thank Michael Biebl for drafting an option which (although I strongly disagree with it, and with its framing) clearly represents the views of the pro-systemd-integration community. And I would like to thank my friends and partners for their support, without which I could not have coped.