Bug#727708: init system coupling etc.
Preface: I'm not involved with the Debian project directly other than as
a user. So while I personally have strong opinions when it comes to the
init system, so far I have just followed the debate because I didn't
feel it would be helpful to spam this bug with useless comments. That
said, I have thought about the coupling issue for quite a while now and
I firmly believe that the original L and T options are BOTH explicitly
harmful (in different ways). For this reason, I feel the need to express
my opinion on this subject. But after I have said my piece, unless there
is a need for clarification on my side, I will walk back to the
sidelines and continue to watch.
First of all, I do think there are legitimate concerns that lead to both
the T and L options. On the one hand, the L text is clearly motivated by
the worry that if a huge part of the Debian ecosystem (*cough* GNOME
*cough*) suddenly depends on a specific init system (*cough* systemd
*cough*) then the commitment to multiple init systems gets reduced to a
farce. People might disagree about whether this is in reality going to
become a problem, but I think the concern is legitimate. On the other
hand, the T text seems to be motivated by the wish to not hamper
progress when it comes to software, that the Debian project should not
hold software back because of some ideological reasons.
That said, I think both texts are problematic: L being far to extreme in
its scope and T being far too toothless in the side sentence about
"encouragement" when it comes to support for other init systems.
The problem I have in this discussion is that only a few cases have been
picked apart in detail, but the wider implications of these options have
been mentioned in passing at best. So for this reason, I'd like to
propose several different scenarios where the coupling question applies,
so that the consequences of language used in the coupling question
becomes clear. So let me draw up a couple of scenarios:
(A) Someone writes a GUI for managing systemd that has the goal of
providing access to as many features as possible, so that it really is
tightly coupled to systemd in that sense. There is no way this could
realistically be ported to other init systems. (Although a different
software for e.g. upstart could be affected in the same way.)
(B) Someone writes a GUI for accessing journald files on the hard drive.
(C) Someone writes some kind of framework that depends on advanced
systemd features, such as systemd-nspawn, to provide a novel technical
solution. This software is new and not yet widely adopted. (Somewhere in
the original discussion before all of the ballots, somebody mentioned
something akin to this, I just don't feel it makes sense to invest the
time to dig that up.)
(D) Someone writes a daemon that currently only works with systemd, but
a patch for including sysvinit and upstrart support is literally only 5
lines of code.
(E) GNOME depends on logind interfaces and there is not working
alternative logind (>=205) implementation available.
(F) GNOME depends on logind interfaces and somebody stepped up and
created a logind implementation for other init systems.
(G) GNOME starts to depend on systemd as pid1 irrespective of logind.
(H) Some software part of the default install set (which currently does
not include GNOME but might again in the future) depends on systemd as
PID1, either directly (see G) or indirectly via logind with no
alternative implementation (see E).
I think that both "L" and "T" options have undesirable consequences. (To
clarify: I consider some of these to be undesirable for Jessie, not
necessarily for later releases.)
Let me start with "T":
- Most serious case (H): If any software in the default install set
depends on systemd, then this IMHO creates the de-facto situation
that there really only is systemd support. Because if you can't
switch the init system if you have a default set of software
installed, saying that you support multiple init systems is a farce.
Therefore, I definitely think that any resolution by the TC should
include language that says that any software in the default install
set should work with ALL supported init systems (with degraded
operation being possible).
So in the case of GNOME, if it continues to depend on logind (likely)
and there doesn't happen to be a logind implementation that works
with all the other init systems (unknown), then that should
definitely disqualify GNOME from being made default desktop again.
(OTOH, if there IS an alternative logind implementation at the point
where this is decided, this doesn't stand in the way of GNOME
becoming the default desktop again, but obviously it will also not
make GNOME automatically the default desktop, that will depend on
other things. ;-))
- Case (G): I don't think this is likely to happen for Jessie, but I
do think this should be addressed. Since GNOME is one of the major
desktops used by Debian users, I do see its position different from
new, unadopted software. GNOME has a certain "market power", so if
it starts depending on a specific init system (and by that I DON'T
mean logind-type dependencies, I really mean explicit ones), I can
understand why people feel that things are "forced upon" them. So I
think this case should be avoided, at least for Jessie. Consider
this akin to some kind of "antitrust law", i.e. if Debian is serious
about commitment to multiple init systems for Jessie, a piece of
software as major as GNOME should not depend *directly* on a single
init system. (Transitive dependencies aka logind are a different
- Case (D): The "T" text encourages maintainers to include support for
other init systems, but you could imagine a stubborn maintainer that
refuses to even include a patch as trivial as described in that
scenario. For this reason, I think the language could be made
stronger at this point. But read my critique of "L" first, why I
don't consider myself a supporter of "L" here, I just think that
for this specific case, where support really is absolutely trivial,
I think that stronger language might be needed. OTOH, you could argue
that for these cases, the TC could override stubborn maintainers, so
the encouragement might be enough to set a general policy.
- Case (B): In that specific case, I actually think this is the same as
case (D). Just because it reads journal files and has a nice GUI, I
don't see any technical reason for the software to require systemd as
PID1 (just that there won't be any new journal files generated in
that case), and actually having something that reads journal files
even on systems booted with another init might really be useful. 
Now to the things I don't like about "L":
- Case (A): This is one of the cases where I see "L" as the most
harmful: Somebody writes a tool that improves upon a given init
system, but is not part of it (as such, not falling under the
exception made in "L"), and that can't be included in Debian.
You might argue that it does indeed fall under the exception,
but I don't see how you could think that, unless it is officially
adopted by the systemd devs. This could actually lead to the really
perverse situation that systemd is the default init, but the TC
decides to forbid the inclusion of tools that make life with the
default init easier for system administrators.
- Case (C): Again, here I think "L" is actively harmful. Somebody
writing a NEW piece of software that makes use of systemd's
facilities to provide a new, awesome (in the author's eyes at least
;-)) technical solution to some problem, and then Debian saying that
it's policy forbids to include it, because it might force people
into using systemd, seems absurd to me. As I said above, when it
came it to the GNOME issue, I would like to make a distinction
between software with a certain "market share" that is already
established, and software that is new (or for that matter, software
that isn't new but in the past hasn't had that much of an install
Now to the meat of the matter: logind, or transitive dependencies on
interfaces provided by systemd, but at least in principle not
necessarily tied to systemd. I think there is consensus in the TC about:
- logind being a dependency is not a problem if there are multiple
implementations of it, so that it works an all init systems.
I think the difference in opinion boils down to:
- who should have the onus to make logind work for !systemd?
- Either the maintainers/devs of other init systems
(This also means that if those people don't step up, GNOME will
be allowed to indirectly depend on systemd because of this.)
All the "T" people appear to take this position, but also
Steve Langasek 
- Or the GNOME maintainers
(or whoever else wants to use logind)
Ian Jackson sems to take that position , if I read his email
- Or the systemd maintainers
Personally, I think it's ridiculous that the systemd maintainers should
do that (and I'm not sure anybody has really argued for that, even
though Steve Langasek seems to think  that that is Ian Jackson's
position in ).
So you have the realistic choices of logind-using-software-maintainers
vs. other-init-maintainers. I think I personally would go in the
direction of other-init-maintainers. I don't see a violation of the
"antitrust law" analogy I made above, simply because I think that in
case of logind, other init systems are given the appropriate chance, and
it is their problem if they decide not to take it. But I see that people
can reasonably disagree here.
To summarize: I think both "L" and "T" are both actively harmful. I have
provided a list of scenarios (obviously not exhaustive, but probably
good enough) which I think capture the different situations that might
be affected by a decision on the coupling issue and given my opinion on
those issues. What I think should be in any resolution is:
- Default install set should NOT include anything that depends on a
single init system (other than the tools coming with the default
init system, obviously).
- On the one hand, software packages with a wide install base should
have a bit of an extra onus in that direct dependencies on a
specific PID1 should be disallowed (indirect dependencies such as
logind should be part of the vote), i.e. my "antitrust" analogy.
- On the other hand, depending on systemd (or upstart or OpenRC, for
that matter) should be allowed for software that is new or has
never been "big" in the ecosystem. Otherwise, I think this will
severely retard progress. See my discussion of cases (A) and (C).
(Also, I don't think this should be restricted to default init,
if somebody wants to write an awesome new solution that depends
entirely on upstart or OpenRC, I think they should be free to do
- But if adding support for other init systems is trivial for a
package (missing startup script etc.), there should be some kind
of clear statement about that.
- To summarize as a short sentence: allow dependencies when necessary,
forbid them when possible.
- The ballot itself should then be about the disagreement of who
has the onus when it comes to transitive dependencies.
Also, generally speaking (but I think there is already a rough consensus
in the TC on that), I don't think it's wise to set policy for beyond
Jessie NOW, since Jessie+1 will be released at least 3 years from now,
and systemd itself is for example less than 4 years old (Lennart's
"rethinking PID1" blog post is from April 2010), so a lot can happen in
Finally, there is the aspect of whether the TC should actually make a
policy decision the coupling issue, I've heard claims that the question
was not put before the TC and therefore the TC should only give advice,
because it's not in its power to do otherwise. Correct my if I'm wrong,
but wasn't bug #726763  the straw that broke the camel's proverbial
back that led to this discussion? I have to admit that all I know about
Debian politics has come from reading the init system discussion (which
is probably not the best introduction to it ;-)), but it appears to me
that the coupling question is definitely something that the TC is
allowed to address and probably actually SHOULD address. #727708
currently blocks the resolution of #726763 - so if you say that you are
not going to rule on the coupling question, what is going to be TC's
answer to #726763? With the current decision, which just affects the
default init system, I don't see a clear unambiguous response to that
bug from the TC. Just to give my 2¢ on that topic.
Anyway, I hope that my thoughts on this matter were helpful and I do
apologize for the length of this email, but since I have now said
everything I wanted to say about this topic, I can now step back and
stay out of it.
 Btw, I think systemd's own journalctl doesn't require
systemd-as-PID1, so it might be a good idea to split the journalctl into
a different package, so that people using other init systems could
install it to read journal files generated on different systems. But
this is just a tangent, so please don't focus on this... ;)
PS: Also note that this email represents my opinion given the
constraints of the current Debian project and/or ecosystem, this does
not represent my opinion of how I would design a Linux distribution from
scratch if I had the time.