Ian Jackson

Sam Hartman, the Debian Project Leader, has proposed a General Resolution (a plebiscite of the whole project) about init systems. In this posting I am going to try to summarise the situation. This will necessarily be a personal view but I will try to be fair. Also, sorry that it's so long but there is a lot of ground to cover.

Pithy summary

The current political atmosphere has been turning bugs into fights. We need to stop this, and try to turn our fights back into bugs. The parts that need to be nailed down are:

• whose job it is to fix the bug? (or, what happens if the bug is not fixed?, which amounts to the same thing);
• when the bug is fixed take the patch already!; and
• everyone stop with the dissing, negging, and concern trolling, already

I think we can do this (well, the first two, at least) with my proposal.

Philosophy

My starting point for all of this is what I have written at the top of my proposed alternative to the DPL's GR texts:

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.

This is particularly important for a project like Debian. Debian plays a very central role for a lot of people. It is at least as much a clearinghouse or a marketplace, as it is a unified system. Supporting a different init system or a different menu system or whatever is fairly easy to do if done within Debian (if the Debian maintainers will take your patches) but a lot harder to do downstream.

Conversely, specialising on particular use cases is very easy to do in a derivative. This means that Debian needs to remain as general as possible, even if that means it suffers a bit in dominant use cases.

Background

In 2014 Debian changed to use systemd as the default init system. The intent (at least of those on the TC making that decision) was that other init systems would continue to be supported.

Since then, Debian has still continued to support sysvinit and other systems such as runit and OpenRC. sysvinit support was very good in Debian 9 ("stretch").

In Debian 10 ("buster", currently "stable") there are some snags with desktop software, much of which nowadays usually wants interfaces provided by systemd's logind component. elogind can provide this under sysvinit, but the package dependencies are awkward and there are some other wrinkles. Also the sysvinit package was looking rather undermaintained.

The Debian Ecosystem Init Diversity Team

In response, we assembled a team of people who cared about these issues. The team includes Debian Developers, developers from Devuan and we also have contributions from (for example) the recently revitalised sysvinit upstream. Working with the folks from Devuan has been great. I want in particular to say a huge thank you to Mark Hindley.

In bullseye ("testing"), sysvinit is getting plenty of love and is in reasonably good shape. We have a close relationship with sysvinit upstream. Support for desktop software is provided by elogind, which is a logind derivative developed for use in Guix.

Unresolved issues

However, the Debian Project as a whole remains very unsettled about init systems. Everyone has a lot of baggage, and there are some specific unresolved issues too.

Toxic atmosphere

One huge problem is that conversations on the Debian mailing lists about sysvinit or systemd-related features are generally extremely toxic.

There is a significant contingent within Debian who seem to be hoping that non-systemd systems would just go away so they could have the beautiful sunlit uplands of homogeneity. Comments predicting the demise of sysvinit, with a subtext that systemd sceptics have lost and should shut up and go away, or at least that they are doomed, are common. The implication (usually not stated so baldly) is "we decided for systemd n years ago, isn't it time to throw that other stuff out yet?"

Conversely, systemd sceptics in these conversations have been defensive, embattled and bitter. Predictions of systemd hegemony lead naturally to responses citing alleged systemd misfeatures, bugs and absurdities. And sometimes the responses from systemd sceptics just have been very nasty.

Debian has generally suffered from problems with toxic culture and has struggled to improve and to manage the behaviour of some of its contributors, and struggled to deal with obstructive maintainers. On this particular issue the political context, and the ongoing fights (read on), make it much much worse.

Blocking of init diversity work

An underlying reason for the bad feeling amongst systemd sceptics has been a pattern of obstructive behaviours by some people within Debian.

For example there have been vague and unactionable RC bug reports against pieces of the non-systemd ecosystem. Requests to core package maintainers to accomodate non-systemd setups in their dependencies are approved very slowly if at all. [1]

Blocking of policy updates; init scripts

Debian Policy still talks basically only about init scripts. We need policy that reflects reality and gives useful technical guidance on how to make things work properly with systemd, and how to make things compatible.

Nominally, policy says that you MUST have an init script if you have a systemd daemon service unit. But no-one is filing these bugs. This is probably because a contributor would not expect a useful response; also, Debian's processes for review of maintainer decisions can be quite unpleasant [2]. The current policy wording de facto encourages the mere filing of an RC bug (ie, a demand that the maintainer do the work) rather than the contribution of a patch.

The policy discussion process is unsuited to controversial issues. Usually policy changes only by consensus. It is clearly not possible to achieve consensus to drop the mandatory requirement for init scripts, since systemd opponents are unhappy with that - in particular because RC bug status is Debian's only really useful mechanism for dealing with an obstructive maintainer.

The policy maintainers are quite reasonably reluctant to make changes in this area without a clear indication of direction from the project.

Blocking of use of useful, portable, interfaces from systemd

systemd has some useful features that we could probably make use of in Debian without giving up support for non-systemd init systems. Particularly it offers declarative syntaxes for various common tasks which we currently do with debhelper scripts.

Many of these do not depend on systemd itself, and are not particularly complex. They would not be hard to reimplement (that being the standard approach to providing compatibility when the atmosphere is less fraught). Some of us have been hoping for more declarative approaches for some time, so there would be value here.

Normally in Debian someone who wanted to transition to such new scheme would provide the relevant implementations (perhaps several), do a few demo packages, document it in policy, and eventually (after some years) we would have lintian warnings about the old scheme. People who want to improve Debian must generally file patches[3] even when the maintainers are sympathetic but maybe busy.

However, people who think that systemd is the future (and that other init systems are obsolete) see reimplementing systemd features in other programs as wasted effort, and systemd itself is not structured to make it easy to tease out its implementations of some of its features. Conversely, people who dislike systemd are not likely to agree to the inclusion in policy of requirements they see as extending the systemd hegemony.

It is not unusual in Debian to see valuable changes blocked [4], sometimes for many years. But it is not a good thing - and this stuck issue provides additional fuel for the political fires.

The upcoming General Resolution and the position of the DPL

The current DPL thinks that trying to resolve the unresolved tensions over systemd is necessary for the health of the project. That is why he has brought this issue to a head by making a set of GR proposals.

Sam is framing this as a question of the project's priorities. The solution, for him, seems to be to simply and definitively answer the question of whether the project is going to support only systemd, and how much of a commitment we are to make to it.

I think that is the wrong framing. As I say above I think Debian needs to be the place where you can come to do your work, and we need to welcome everyone's contributions even if we don't think they're particularly valuable. That is the basic bargain underlying the common project.

Sam's middle option is not a compromise, and sets us up for more fighting

The most likely outcome of a choice just between the DPL's three options would probably the second one, which has been placed in the "middle" and labelled "systemd but" (as if dropping systemd were even on the table). But it is a poor text - vague and unbalanced.

It does not clearly and specifically address many of the problematic behaviours I discuss above, so it would set us up for more years of fighting over details.

Although it reads vaguely like a compromise ("however") and has been placed in the middle of the list, it will in fact make things things quite difficult for contributors and users who don't want systemd.

It doesn't clearly contradict the notion that "systemd is the future and other things are obsolete or experimental", which continually undermines work on systemd alternatives (for example, we have had maintainers ask on debian-devel whether they should remove their init script now they have a systemd unit file). It legitimises uncoordinated adoption of systemd features and make it unnecessarily hard for sysvinit etc. to keep up. It does nothing to help contributors whose non-systemd support contributions are rejected: for example, init script contributors would still need to fight those unreasonable rejections piecemeal.

On the approach to process

Sam has taken the unusual approach of drafting three alternative options himself. He has also taken a rather autocratic approach to the timetable. I strongly disapprove of this.

He has put himself in the position of trying to frame the debate along the lines that he sees, which is not right. Different constituencies have different framings, and are entitled to have those represented. People who see things differently should not be put in the position of opposing the leadership, and scrabbling for resolution seconders on needlessly tight timescales. The drafting of options should be led by the people whose opinions they are.

My position: Keep Debian a do-ocracy

The question of whether Debian supports running without systemd needs to be answered not by strategic decisions over priorities. That amounts to to to deliberately excluding people's contributions. I can see how that is tempting, because inevitably diversity comes with a price for everyone. But that diversity is how we built our community, and it is particularly important for Debian's role as a central clearinghouse, and indeed our role as an upstream to a whole ecosystem of derivatives.

We should look at the question we usually ask (eg about whether to support architectures): are there enough people who want to support non-systemd setups, and are they willing and able to do the work ?

If there are we should support them. We should take their patches and support and enable their work. If there are not, then quite significant obsolete software can and will die its death fairly quietly, without the need for blocking, fighting, negging and concern trolling.

Unfortunately it appears that enough people in Debian aren't able to be reasonable and constructive, at least without being set clear and specific boundaries. Setting those boundaries is what I am trying to do with my proposed option. If you are a full voting Debian Member, I would appreciate it if you would please formally Second my proposal. I have more than the minimum of five already - thanks Russ, Sean, Simon, Kyle, Dmitry, Noodles - but lots more would be good.

How my proposal helps

Toxic atmosphere

The introduction says we want to support multiple init systems "for the foreseeable future". That directly confronts the narrative that "systemd has won and therefore other things should go away". The introduction explicitly states the principle I started this posting with. There are some specific rules towards the end, where I name particular common toxic patterns; I don't know if our communication fora operators have the will to deal with this but this is the best a GR can do, I think.

Additionally I'm hoping that providing workable rules of engagement will mean that people are less frustrated, and that we don't have to try to wear each other down (which is how fights are traditionally won in Debian - urgh.)

Unblocking non-systemd support

The compromise for init scripts etc., is to encourage submission of patches by making the patches count as RC bugs. Although this is the current formal state in policy, it is not effective because it lacks political legitimacy. This GR gives it that legitimacy. In return we relax the policy MUST in cases where there is no patch. So we are not forcing anyone to do the work.

There are more complex situations where systemd package dependencies, or release team decisions, and so on, are involved. My option gives general guidance (which really ought to be uncontroversial, but has not always been followed). If this is not effective in particular cases then unfortunately the Technical Committee will probably end up having to resolve the disputes. But I think there will be relatively few of these and because of the complexity of the issues it's not possible to decide them in advance.

Unblocking policy development

There is a compromise on systemd's non-init-related features ("declarative" things). Fastest progress could be made for systemd systems if every maintainer was free to simply use every systemd feature. But that is not how we normally do things in Debian. We try to bring the whole community with us, even if that means some delays.

Because questions of timescale are going to be particularly controversial, and are a matter of balancing the interests of different groups, I put in a specific timescale to avoid further arguments. In practice I think when useful systemd syntaxes etc. are approved, the init diversity community will want to implement them quickly to demonstrate their dynamism and relevance.

On the "Init Diversity" counter-proposal

Dmitry Bogatov has put forward an option of his own. I think what Dmitry is trying to do makes sense. His option is the strongest protector of diversity and most strongly reestablishes the usual (albeit not universal) Debian norm that people who want to change things should do all the work. It gives clear political reinforcement to the current de jure policy on init scripts.

In most situations Dmitry's proposal is rather stronger than mine. I think in practical terms my proposal will be quite sufficient to have good support for sysvinit (and indeed other init systems) for the long term. But if you supported my strong init diversity position in 2014 you will want to consider seconding and/or voting for Dmitry's proposal.

This section largely rewritten 2019-11-21 11:03 since Dmitry updated and improved his proposal

Looking to the future

Frankly, there is a lot not to like about init scripts. I have never liked the "detach" model of daemon management (even though I wrote start-stop-daemon to fix its worst bugs). I much prefer setups with closer supervision.

I hope that we can find a better lingua franca than handwritten init scripts, at least for the most common cases. Exactly what that looks like will have to be discussed within the init diversity community.

We do have two other init systems: runit and OpenRC. I haven't tried either of them and frankly I have little idea if I would like them if I did. But we have good relationships between all of the relevant maintainers and users. I hope these projects will thrive.

But so long as the community of systemd sceptics have to be fighting for their very existence, there is little time and little emotional energy for development and experimentation, and adoption of novel ideas.

Acknowledgements

Thanks very much to the several people who helped by reviewing drafts of this posting. Your support and frank comments have been invaluable. You know who you are. All errors and missteps are mine, of course.

Footnotes

[1] I don't mean to be calling people out, but I feel these kind of assertions need to be substantiated so here are some representative examples.

[2] The Technical Committee process is quite stressful. Here's a particularly bad example (where I have mixed feelings about my own part).

[3] all reproducible builds bugs (warning: huge)

[4] Debian is famously slow but here are a couple of my pet examples.

Edited 2019-11-20 12:20 UTC to fix some HTML formatting issues with some blog aggregators.