Debian reconsiders init-system diversity
The new systemd discussion had been simmering for some time before flaring up in late 2018 when it became clear that the project had been unable to fully support systemd alternatives due to a lack of developer interest. The current discussion, instead, is a direct result of Debian project leader Sam Hartman's Bits from the DPL posting on October 29. Therein, he stated his belief that a new general resolution on init-system support is necessary, and that he would be proposing one in the near future.
The immediate motivation for a reconsideration would appear to be the proposed addition of elogind, a standalone fork of the systemd-logind daemon, to Debian. Elogind would provide support for systemd's D-Bus-based login mechanism — needed to support small projects like the GNOME desktop — without the need for systemd itself. The addition of elogind has been controversial; it is a difficult package to integrate for a number of reasons. Much of the discussion has evidently been carried out away from the mailing lists, but some context on the problem can be found in this bug report. In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems. It seems possible that this commitment no longer exists across the distribution as a whole; the purpose of a general resolution would be to determine whether that is the case or not.
Feature pressure
Unsurprisingly, Debian developers have a variety of opinions on this issue.
This response
from Russ Allbery is worth reading in its entirety. He argues that the
2014 decision (of which he was a part) never really nailed down the
project's position toward other init systems. That was a necessary
compromise at the time, he said, but it is causing stress now: "while
I feel
somewhat vindicated by the fact that this didn't immediately fall apart
and has sort of worked, I think it's becoming increasingly
untenable
". The time has come, he says, to make the project's
position clear so that developers can and will do the right thing:
Josh Triplett zeroed in on one of the issues that is testing the init-system peace now. There is, he said, an increasingly long list of features that are only available with systemd, and application developers want to use those features:
Today, people can't use systemd persistent timers in place of cron (and in place of anacron's "wake up periodically" approach). [...]
Systemd user sessions, socket activation, sysusers, dynamic users, systemd-homed, temporary directory setup, transient units, anything talking to the slice or control group APIs, containerization, firstboot, systemd's whole "preset" system-wide configuration and policy mechanism for admins to say "what services do I want launched when installed and what services do I want to leave stopped until I configure them", "stateless system" capabilities, and I'm probably forgetting another dozen.
The responses to this argument took a couple of different approaches. Ted
Ts'o described those
features as "the 'embrace, extend, and extinguish' phenomenon of
systemd which caused so much fear and loathing
". Debian has avoided
much of this stress until now, he said, because it ships a relatively old
version of systemd, but that won't last forever. Upstream developers are
going to use newer systemd features, and Debian will have to accept that if
it wants to package and ship their code. "I don't think we have a
choice but acknowledge reality and accept that some packages may simply be
incompatible with alternative init systems
". The situation doesn't
make him happy, he said, but there is little to be done about it.
Allbery, instead, suggested that the project could decide on a set of interesting systemd features, then create non-systemd implementations of those features where necessary. That is essentially what is being done with elogind, for example. All init systems could be made to parse systemd unit files, and there would be a minimal set of directives they would be expected to support. There would, in effect, be a definition of the ABI an init system must support, rather than any rules about specific systems. Done properly this approach could ease the feature pressure, but there is one little problem:
Some, like Ian Jackson, claimed that much of this functionality already exists and works. Svante Signell also argued that the systemd alternatives are well maintained and that Debian should remain open to contributions from developers who are working on those alternatives.
Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place. That, Allbery added, is the question that the project has to answer: what will be Debian's policy toward software that requires features that will be specific to systemd? Should there be a specific subset of systemd features that Debian software will be allowed to depend on, with the idea that alternative init systems will eventually gain implementations of those features?
The first GR draft
Hartman posted a draft general resolution on November 7 that does not directly address Allbery's question. It focused strongly on init systems, rather than support for advanced systemd features; there are three alternatives:
- "Affirm init diversity": running init systems other than systemd is an important project goal, and provision of init scripts would remain mandatory.
- "Systemd but we support exploring alternatives": systemd would be the preferred init system, but alternatives would remain important; elogind is given as an example of the sort of project that should be supported. Hartman posted another message with a detailed description of what this option might imply.
- "Systemd without diversity as a priority": there would be no requirement to support anything but systemd in Debian.
Hartman thus appears to have left out Allbery's suggestion of defining an init-system ABI entirely. It should be noted, though, that this is explicitly a draft; it is likely to evolve considerably before it reaches the point where the project will vote on it.
There is one final bit of context to consider as part of this vote: according to
Marco d'Itri, it has already happened. "We have already voted
with apt: less than 1% of new installs use sysvinit
". That suggests
a relatively low level of interest in systemd-free Debian. Perhaps users
with that interest have moved to Devuan
but, to all outside appearances,
progress there has slowed considerably since its developers fell out with each other in April. Even
if Debian chooses to continue to support multiple init systems, it is not
clear that the development effort to make that support work will be there.
The free-software community values diversity and choice in its systems. But we also value standardization and the progress that can be made when we all focus our efforts on a single system. Many parts of the Linux system are essentially monocultures: examples include the kernel, the C library, and, until relatively recently, the compiler. There are strong arguments in favor of both standardization and diversity. In the case of GCC, the lack of competition is often cited as a cause for a long period of relative stagnation. If one looks at desktop environments, instead, it is often said that the scattering of developer effort has prevented the success of the Linux desktop as a whole.
It would thus seem that there is no obvious answer to the question of
init-system diversity, regardless of how one feels about systemd in
particular. Most community distribution projects have long since decided
that they lack the resources (and maybe the desire) to support multiple
init systems. Most of those, especially the larger ones, have settled
on systemd, even if they feel that a viable alternative to systemd would
be good to have. Debian has, so far, been an exception to this trend. It
will be interesting to see whether the project has the will and the
development resources to continue on that course.