A Debian init system GR flurry

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

One might have hoped that that Debian systemd debate would have wound down several months ago, after the technical committee decided the default init system question and especially after Matthew Vernon's general resolution on init system choice was withdrawn due to a lack of seconds. The Debian community, it seemed, was tired of this discussion and ready to move on. Given a few months to rest, though, even old, tiresome subjects can once again seem worthy of discussion. So now we have a return of the init system choice resolution — along with three alternatives of varying scope.

The GR returns

On October 16, Ian Jackson reposted Matthew's general resolution text as a new proposal. The core of this text is simple enough: "In general, software may not require a specific init system to be pid 1." There are some obvious exceptions — init systems themselves, for example — but the point of the resolution is that nearly the entire Debian distribution must be able to run, with nearly full functionality, under multiple init systems.

In March, this proposal failed to gain the required six seconds to go forward to a full-project vote. This time around, instead, the seconds came quickly, so the proposal will be voted on in the relatively near future. But the increased availability of seconds does not mean that there is a clear consensus behind this proposal.

One of the biggest concerns is about the effect this resolution will have on the upcoming "jessie" release, which is due to head into a feature freeze on November 5. Adding a new set of requirements to the distribution at this time, some think, is a sure recipe for delaying the jessie release. It has been pointed out that, seemingly, there are no packages in Debian now that require a specific init system, so no changes should be required for jessie. To some, that means that the resolution is not needed at all; others say that this is just the right time to address the issue before it does become a problem. In any case, Ian has added an amendment (which, like all of the options, can be seen on the Debian vote page) making it clear that this resolution is not expected to delay the jessie release.

Another objection is that this resolution imposes work on developers by forcing them to support multiple init systems whether they want to or not. Not forcing developers to do work is one of the core principles enshrined in the Debian constitution:

Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.

The question, is thus, whether rules on init system support constitute assigned work or whether they are simply rules that a developer may not act against. The case for the latter is perhaps best expressed by Steve Langasek, whose message deserves reading in full for those wanting to know where the motivation for this general resolution is coming from. As Steve put it:

It is a form of compulsion that is legitimate under our constitution. There are some times when letting every DD do their own thing is not the right way to build a shared operating system.

Russ Allbery, instead, sees the init system issue as being similar to Debian's adoption of udev or the fact that Debian only works with one C library. He has a lot of faith that, as with previous issues, this one will work out over time if Debian developers are allowed to do what they see as the right thing. The general resolution, he thinks, is not the path toward that goal:

I strongly believe that this proposal is well-meaning and put forward with the best of intentions. However, I also strongly believe that a vote in favor of it is basically a vote for constant flamewars and hostility in our community, and is likely to make it *less* likely that people will port things to non-systemd init systems due to the natural backlash against people who are not doing the work telling them how to do their work.

Anthony Towns takes a bit of a different approach, seeing init system support as a policy issue. Policy is not normally set by general resolution in Debian; instead, there is a policy committee charged with handling such issues. In his view, no developer could be compelled to add support for multiple init systems to a package, but, equally, the release managers could not be compelled to include that package in the distribution if policy argues otherwise. Anthony has a github repository containing his suggested policy changes.

Alternatives

While some developers have taken positions of opposition to Ian's proposal, others have taken the approach of offering amendments — alternatives that will be voted on with the initial proposal. As of this writing, there are three of these amendments, varying considerably in their approach to the problem.

The first of these, put forward by Debian project leader Lucas Nussbaum, aims for init system diversity but applies a lighter hand. Where Ian's proposal uses, in IETF terms, "MUST" phrasing, Lucas's uses "SHOULD" instead. The proposal says that packages should support the default init system on the architecture for which they are built, and that packagers should accept patches that increase init system portability in general. This proposal points in generally the same direction as Ian's, but it takes the form of advice rather than commandments.

The second amendment came from Luca Falavigna. It states that:

Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent.

It goes on to say that a developer's technical decisions will not be overruled in the absence of documented defects, and that "fear, uncertainty, and doubt are not considered as evidence of defects." This amendment clearly runs counter to the first two, in that it explicitly allows developers to create packages that are dependent on a specific init system.

The final amendment comes from Charles Plessy. It states, simply, that things are working well as they are now and that no general resolution is needed. It could be thought of as an alternative to the required "further discussion" option that, with luck, would allow the project to do without having to actually endure further discussion on the subject.

Further discussion

If there is one thing the past few years of systemd debates have shown clearly, though, it's that further discussion is almost inevitable. Those who see systemd as the answer to a long list of system administration problems are unlikely to give up on exploiting its features to the extent that they are useful. Those who do not like the systemd approach or its development community, or who have, as Steve put it, "grave misgivings about Debian being tied to an upgrade treadmill by an upstream that may pay little heed to things that matter to Debian's community in the absence of a forcing function" are unlikely to be comforted without several years of experience to the contrary. With positions this far apart, one can be assured that there will be more to talk about.

The immediate question should be answered within a few weeks; this resolution is likely to go to a vote in early November. Whether that answer puts the issue to rest will depend on a number of things, starting with the Debian community's willingness to accept the answer and return to work putting together the jessie release. A stronger show of a desire to cooperate and respect Debian's concerns from the systemd community would certainly not hurt. Both communities will also have to make a point of ignoring the large mob of trolls that seems to revel in stirring up flame wars on this topic wherever it can.

That's a tall order, but, as Russ put it, Debian has been through many large, controversial decisions in the past and has always come out strong. There is no reason to believe that the project will fail to live up to that history this time around. But the process of getting there may be a bit messy for a while, yet.

