Bug#727708: init system coupling etc.
Christian Seiler <firstname.lastname@example.org> writes:
> 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.
Well, the T language wasn't written by me, but I should clarify that's not
what I'm trying to say in my proposals. I think Debian should do lots of
things for ideological reasons. One of the pieces of Debian ideology that
matters a great deal to me is that we should trust our package maintainers
to choose how to package the software they maintain, and trust their
judgement about the approach that provides the best, most high-quality,
and most integrated experience for our users.
In other words, what I want to do is defer to package maintainers, who
are, after all, experts in the packaging of their software, to make good
decisions. The TC should only get involved where there are irreconcilable
conflicts about how to do this, or when the project asks us for guidance
on how to achieve distribution-wide integration.
I feel like an argument could be made that the project has asked us for
advice on this (although I think a good argument could be made that the
project has *not*, which is Keith's point). I'm trying to express that
advice while continuing to recognize and respect the fact that Debian
defers, in nearly every case, to the informed technical judgement of the
packager or packaging team, and generally tries to address most conflicts
by enabling the parallel packaging of software with different approaches
rather than choosing a single winner and rejecting all other "competing"
packages. I'm also trying to respect the core foundational value of
Debian that volunteers get to work on what they choose to work on, and no
body in Debian has the authority to order people around.
I found your specific cases a useful clarifying exercise to lay out how I
think about this, so let me respond to each of them:
> (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.)
This clearly should depend on systemd and should be allowed.
> (B) Someone writes a GUI for accessing journald files on the hard drive.
Depending on how this is written, it may depend on the package providing
journalctl or it may depend on some shared library that implements the
journal reading code, or it might even have no dependencies at all if it
implements the journal reading code itself.
> (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.)
This clearly should depend on systemd and should be allowed.
> (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.
Assuming that this is a new package not previously in Debian, and after
systemd has become the default init system, I think it should be fine to
introduce this package with a dependency on systemd until such time as
someone actually writes and tests that patch. Once that patch is written
and tested and submitted, the maintainer should incorporate it and drop
the dependency. (Constitutionally, I don't think the TC should require
maintainers to do this in advance, but if this actually got escalated all
the way to the TC as a maintainer override, something that I really hope
would never happen and I see no reason to believe would happen, I would be
baffled by why the maintainer wouldn't include such support.)
> (E) GNOME depends on logind interfaces and there is not working
> alternative logind (>=205) implementation available.
(I don't know of any reason why GNOME would specifically need to depend on
a post-205 logind at this point, so I'm replying to this without the
I think this should be fine. But this is a controversial case that we
have strong reasons to believe won't actually arise, so it's not clear
whether there's any need to argue about my position on it.
> (F) GNOME depends on logind interfaces and somebody stepped up and
> created a logind implementation for other init systems.
In this case, I think GNOME should allow either implementation to satisfy
its dependency. I think that's uncontroversial across the board,
including with the GNOME maintainers.
> (G) GNOME starts to depend on systemd as pid1 irrespective of logind.
There doesn't seem to be any technical reason why this would be necessary,
so I think this is inappropriate. I believe that's also the opinion of
the GNOME maintainers; in other words, they have no intention of doing
> (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).
There don't appear to be any technical reasons why this would be
necessary, so I think this would be inappropriate for the same reason.
> 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. ;-))
The GNOME part has been discussed at length here. I'm fairly sure that
the situation we'll end up with is that GNOME will depend on the
disjunction of the available logind implementations, and Steve is
extremely confident that logind will be available under sysvinit for
It's possible that, in the long, long run, GNOME will want to depend on
systemd to use systemd for session management, but it's already been clear
on this thread that this won't happen for jessie, and it's not at all
clear whether this will ever be necessary or whether there will always be
a fallback available. It is obvious, at least as I understand it, that
this won't be necessary or something anyone is considering for jessie.
> - Case (G): I don't think this is likely to happen for Jessie, but I
> do think this should be addressed.
In general, I part company with you at this point. If something isn't
likely to happen, I *don't* think it should be addressed. In fact, I
think it *should not* be addressed. We have enough immediate issues;
let's not borrow trouble by both addressing things that are unlikely and
then lecturing our developers about how to handle cases that they're
probably quite capable of handling themselves.
> - 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.
In general, my feeling is that Debian maintainers do not have to be
carefully programmed to do exactly what the Technical Committee thinks
they should do. The default should be to allow maintainers to use their
own technical judgement.
If maintainers do something particularly bad or contrary to overall
project goals, we can deal with that when it happens and we have
mechanisms to do so, but treating maintainers like they will do that
proactively is paternalistic and unnecessary.
I'm going to skip through more of the analysis here, and just walk through
your list of things that you think should be in any resolution:
> 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).
The default install set is determined by the installer team. I don't
currently see any need for the TC to get involved in their work, and I
don't think the d-i team has asked us to do so. I think they are quite
capable of weighing these issues and making appropriate decisions about
the default install set, or expressing their concerns to other package
> - 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.
In general, I agree with this, and I also think that the maintainers of
such packages would generally agree with this, because of the impact that
they have on the distribution. However, they have to balance this concern
against the fact that some of those software packages (such as desktop
environments in general) also have the most need and demand for advanced
facilities. These packages often stress the limits of the capabilities of
the system in ways that the "average" software package does not.
That balance is difficult and tricky, and I think our DE maintainers by
and large do an excellent job at this. I have a strong preference to
letting them go about their work.
We have one specific issue around logind that is likely to affect GNOME
and KDE and possibly others, and we've talked about the solutions in
detail and Steve is confident that we can solve this issue for sysvinit
for jessie. If there are other issues like this, I think the DE
maintainers and the init system maintainers and possibly the porters
should talk it over, and if they need us to get involved, we'll always be
here. But most of these issues can be worked out amicably without any
need for TC involvement.
> - 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
I agree with this.
> - 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.
I agree with this as well.
> - To summarize as a short sentence: allow dependencies when necessary,
> forbid them when possible.
I don't like the idea of the TC forbidding things at this point, but I
think that's a good summary of what I think maintainers should do (and I
think what maintainers will do).
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>