History

The Debian tech committee is deciding on the default init system for Debian. Personally I’m totally biased and think the only realistic choice is systemd. I loved Upstart when it was written, but actually I think the default init system is really of no concern at all.

What you get with systemd is something which strives to be “the basic building block for Linux” (just watch one of the presentations regarding systemd). All the other init systems either don’t want to do this, or actively strive to do as little as possible. As a consequence, loads of functionality offered by systemd is either only available with systemd, or the alternatives (Canonical logind) are striving to follow what systemd does. There could be lots of alternative implementations as various extra functionality is available through D-Bus interfaces. D-Bus means that the same functionality could be offered by something else.

Note that I read and follow loads of projects. Distribution wise I follow openSUSE, Gentoo, Debian, Mageia, Fedora and Ubuntu (last one minimally as development is not mailing list focused). Then obviously GNOME, systemd, freedesktop, KDE (very minimally), various websites, etc. I’ve noticed that not everyone reads as much as I do 😛

Relying on an init system

One item in the upcoming Tech Committe vote is the following two options

Tight coupling

Software may require a specific init system to be pid 1.

However, where feasible, software should interoperate with
all init systems; maintainers are encouraged to accept
technically sound patches to enable interoperation, even if it
results in degraded operation while running under the init system
the patch enables interoperation with.

Loose coupling

Software outside of an init system’s implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.

Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.

What I don’t like

There are a bunch of things that I dislike about the current status. I think I’d do this totally differently. I like the following quote:

We work for the developer community, helping everyone to work together and make progress. We try not to get in the way.

Anyone who is working in a committee (release team/ctte/etc) has the ability to direct the project. And you’re seen and should be seen as someone who decides. The point is to serve the project and allow people to make progress. On any committee you should not decide, you’re just announcing a decision which was made by others. The same people who are asking you for a decision could be the ones who have actually made the decision. Though always ensure that everyone knows who’s in charge 😛

Lack of distinction of package importance for the distribution

Say you have a package which nobody depends on. Let’s take for example “GNOME Logs”. Nothing depends on it and it is a GUI for the journal (which comes with systemd). Meaning: it relies on a specific init system, and in this case systemd. With “loose coupling”, “GNOME Logs” would not be allowed because it only works with systemd. So I consider “loose coupling” bad. Or would “GNOME Logs” suddenly considered “part of an init system’s implementation”?.

Now consider a package which you need in the distribution. Loads of stuff depends on it and pretty much a requirement to have. With “tight coupling”, the package maintainer could just enable some systemd support, mention other support is not feasible and force the whole of Debian to whatever init system that package maintainer prefers. Allowing maintainers of low level packages to be able to change the Tech Committee decision seems bad. So I consider “tight coupling” bad.

There is a total lack of distinction between the importance of packages as well as the default init system. A low level package could just undo the Tech Committee decision with “tight coupling”. While at the same time, “loose coupling” is a bad option as well as a package which nobody depends on should be totally fine to rely on a specific init system.

Lack of importance for the default

Above choices have no relation to the default init system. Say the Debian GNOME maintainers make systemd a dependency. How is this bad if the default for Debian would be systemd? Say Tech Committe choses Upstart and Debian GNOME maintainers make systemd a dependency. Isn’t the default something that should be considered?

Both options actually encourage maintainers to ensure their packages work with multiple init systems. What if you don’t care? Accepting a patch one time is hugely different from having to maintain the patch.

Now aside from this, if I was maintaining some package that offered better support for whatever init system Debian will use by default, then I’d want to rely on it. Seems nothing wrong with this. It is the default after all.

Burden is placed with package maintainers

If “loose coupling” is chosen and your package doesn’t work with other init systems, then you’re expected to make it work. Say Debian goes for systemd and upstream removes support for anything other than systemd? Too bad, go and implement that support! Say “tight coupling” is chosen and someone offers a patch to make it work on a different init system. Lots of software now depends on this patch. Next upstream comes out and the patch has to be rewritten totally. Well, you’re the packager so good luck uploading the new version.

A one time patch is not maintenance free. The only difference to me between both options who writes the initial patch. Eventually the maintenance burden will be with the packager.

Multiple init system support is always a requirement

Both options demand multiple init system support. With “tight coupling”, packagers are still encouraged to accept patches from a different init system. The burden with “tight coupling” is just with the packagers of the other init system. With “loose coupling”, packagers are forced to ensure it works with multiple init systems.

To me it seems that either way, multiple init system is always a requirement. Just differs where the Tech Committee places the burden.

Doesn’t answer the current issues

To me it seems like the current voting options are not in line with why the question was sent to the ctte. I’ll give a few examples.

logind D-Bus API

GNOME really likes the logind D-Bus API, even if it isn’t a requirement (fallback is the unmaintained ConsoleKit). Now Canonical forked the logind daemon to offer an alternative provider for this API, this fork might be enhanced. At the moment that fork is NOT working in Debian. So can the Debian GNOME packagers or can’t these packagers have GNOME depend on logind and who should do the work?

A reminder on what “loose coupling” means:

Software outside of an init system’s implementation may not require a specific init system to be pid 1

With “loose coupling”, you could argue that an alternative exists, have logind provide a fake package such as “logind-dbus-api” and be done with it. Up to others to package the alternative. Then you can just rely on “logind-dbus-api” and you’re not requiring one init system, though in practice you are, or maybe you are not :-P.

“Loose coupling” seems the option that most of the Upstart supporters will be voting for. Can GNOME require logind API or not? There are alternative implementations. The Canonical fork will likely work with Upstart. But what about other init systems? If those alternative implementations aren’t available or working under all of the init systems, then you might end up requiring a few. Is this bad or not? Or is “a specific init” bad if you want one, but ok if at least two are supported?

I notified the GNOME distributors about this freedesktop.org change back in January 2012 (started with ConsoleKit deprecation, I already wrote multiple blogposts about ConsoleKit and logind explaing this in great detail).

UPower 1.0

For UPower 1.0, some functionality is removed and instead you’re expected to rely on systemd (or anything similar, in practice there is nothing else AFAIK) as that already had the functionality UPower was offering before. This functionality will be gone. With “tight coupling”, that’ll force systemd slowly in more and more things as whatever relied on UPower, now also should have systemd as a dependency. With “loose coupling”, I guess loads of patches in the packages making use of UPower 1.0 to duplicate the functionality UPower 1.0 offered before? Or maybe change UPower 1.0 and make the API different between Debian and non-Debian? It all doesn’t really make sense to me.

I notified the GNOME distributors about this freedesktop.org change back in October 2013.

Glosses over the ability to provide alternative implementations

Say a package requires a D-Bus API provided by systemd, but it could be reimplemented by something else? I fail to see how that is a bad dependency to have. What matters is the interface is implementable by something else. If the API is stable or not. These things should be taken into consideration IMO. It seems to not have been considered at all.

I think it is much better to quality in what way dependencies are allowed. A dependency that currently is tied to a specific init system, while it doesn’t have to be, seems like a totally ok dependency to have. If it is important then someone will eventually do the work. If not, it wasn’t important enough.

CTTE seem to have skipped opportunities for a more thorough analysis

In the whole discussion, I never saw anyone from ctte mention that Debian/Hurd doesn’t make use of sysvinit. I have the strong suspicion that nobody from the Tech Committee went out to ask the porters for their ideas. Then again for the various package maintainers. There was a call, some people who maintain a wiki page, that is it. The problems which resulted in this issue to be raised to the Tech Committee: I don’t think any of the current voting options is going to give satisfactory answer.

Same for checking other distributions. Even Gentoo allows packagers to depend on specific init systems.

Lack of importance of impact on QA

Loads of distributions have switched to systemd. Especially the distributions with a lot of people behind them (paid or not). Now even Gentoo is ok with a systemd dependency. On Gentoo the packagers added a systemd dependency since a few months ago. I know that on Mageia the period where we tried to support multiple init systems had a bad impact on QA. Mageia got way more stable after we switched to systemd only instead of trying to support multiple. There was also a period where Gentoo provided a lot of fixes to GNOME to solve the various bugs GNOME had with trying to support both. But since then loads of code has been moved around. Debian is going to be facing such bugs for the first time with almost nobody to help them out.

Now obviously Debian has loads of volunteers so given enough time and effort everything gets fixed. But it seems pretty much a given that there is a huge extra burden that will be specific to just Debian. The impact on QA (and thus your release schedule) seems like something you should consciously consider.

Consideration to meritocracy

Mageia switched to systemd because everyone who works on the low level bits wanted it that way and they made it happen. To me it always seems good to give consideration to what the people who do the most work in the affected area think. I have no idea though what the ideas are amongst them in Debian.

Guaranteed to be followed up by a GR

I’m pretty sure this will result in another vote, but then open for all of the Debian developers. I don’t like “gut feeling”, I prefer meritocracy. I think it’ll be decided by the gut feeling Debian developers have.

Basic building block vs nothing

To me, the Tech Committee voting is inadequate and misguided. One of the choices strives to be a basic building block. There are interfaces with stability guarantees, but other init systems would just be followers. Further, as systemd strives to be a basic building block, various other projects have or are going to rely on the offered functionality.

Theoretically such functionality can be offered by another init system. Which I like. But currently the Tech Committee seems to have the opinion it is just an init system discussion. This seems an awfully simplistic assumption.

Debian/Hurd and Debian/FreeBSD

Already various differences

Various people really care about Debian/Hurd and Debian/FreeBSD. I find it terribly odd that various people think that there is a requirement that every software should be available under every port. This in direct contrast with the current situation. Debian/Hurd does NOT use sysvinit. According to a porter, sysvinit is not portable. For Debian/Hurd a few hacks had to be added to work around assumptions. On both ports it relies on Linux compatibility layers.

I don’t really understand the purpose of Debian/Hurd and Debian/FreeBSD. By some people, it seems that every current Debian package works under those ports. No matter how low level that package is, it MUST be portable. By some others, FreeBSD offers ZFS and using that on your server in combination with having “apt” is great.

To me it seems terribly odd to have the assumption that everything should be the same while it isn’t at the moment.

Already GNOME barely works on the ports

Another huge problem seems to be that the GNOME packagers want to rely on systemd. This would exclude GNOME from Debian/Hurd and Debian/FreeBSD. However, most GNOME packages already do NOT work on any of the ports. That GNOME works on the real FreeBSD doesn’t mean it automatically is in great shape on Debian/FreeBSD! So there is no practical change, though now people notice the actual situation. I guess it is easier to just assume Debian/Hurd and Debian/FreeBSD are at a good level and a “default system init” has a noticeable impact. It does not. The Debian GNOME packagers wanting to add a dependency is of similar unimportance.

Conclusion

None, I’m just following with interest.