[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: multiple init systems - formal resolution proposal

On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
> No, Josselin was making the technical claim that GNOME 3.10 would need a 
> working logind even for basic functionality.

> So if it is possible to get the basic functionality of GNOME 3.10 
> without a working logind, his claim is just plain wrong.

> And when I was asking him for the technical details that would back up 
> such a strong claim, he was not able to deliver.

> And that does matter a lot, since such claims seem to be the basis
> of all these "GNOME in jessie needs systemd" or "with multiple init 
> systems, GNOME will need a dependency on systemd" (and Josselin even 
> expects an exception from the release managers for that if the TC 
> decision would not allow such a dependency [1]).

Whether or not it's possible for GNOME in jessie to be made to work without
logind, I agree with the GNOME team that logind is a reasonable dependency
for GNOME to have on Linux.

What is not reasonable is the chain of logic that leads from "GNOME should
use logind" to "GNOME will require systemd as the init system".  logind v204
(and the other systemd dbus services) have been made to run on
non-systemd-PID1 systems.  Work is ongoing to provide an alternative
implementation of a cgroup single-writer, that can then expose a
systemd-compatible interface for use with logind v205.  These are not
blue-sky hypotheticals; the first exists in Debian unstable already as the
systemd-shim package, the second is available as an upstream project
(http://cgmanager.linuxcontainers.org/) that will be suitable for use in
Debian well before the jessie release.  And I have already offered my
support to the systemd maintainers to support this configuration going

Yet when I challenge the assertion that "desktop N will require systemd,
therefore Debian must adopt systemd as PID 1", which has been repeated
endlessly in this discussion, I am chided for being insufficiently courteous
to people who do not have the facts on their side.

I have previously suggested that the GNOME team has a reputation for
obstructionism.  I owe the GNOME team an apology for this; as was made clear
to me, in my efforts to not overly personalize the discussion, I instead
erred in the opposite direction by tarring the entire GNOME team with the
same brush.  I will instead limit my criticism to Josselin, who despite
giving the impression of being the spokesman for the GNOME team, is
apparently not speaking for the team as he seeks to cloud the issues around
the technical choices that face this committee.

Assertions that desktops' dependencies on logind dictate the use of systemd
as PID1 are at best a self-fulfilling prophecy which creates a climate in
which people are dissuaded from even trying to do the work to provide
alternatives because they believe these efforts will be blocked by the GNOME
team; and at worst, an overt attempt to distort the TC's debate on the init

Josselin has asserted not only that he considers systemd-as-init a hard
dependency for GNOME in jessie, but that he expects the release team to side
with him over the Technical Committee if the TC does not agree with him.
This is unconscionable, given that there are two very straightforward and
obvious technical solutions to this problem:

 - split the systemd package (as previously discussed) into separate
   binaries, for the init system vs. the dbus interfaces, and have GNOME
   depend on the latter
 - have the systemd package declare one or more virtual packages via
   Provides:, which GNOME packages depend on and one or more alternative
   implementations may also provide.

It is possible that, at the end of the release cycle, there will be only one
viable implementation of these interfaces, and Josselin's prediction will be
proven out.  However, it is crucially not the place of GNOME maintainers to
decide a priori that this *will* be the case, particularly when it should be
clear to everyone that there are developers (myself included) interested in
doing the work to make these dbus services work on top of other init
systems.  This is contrary to the spirit of Debian, and contrary to the very
principle of "reasonable accomodation" that Russ espoused on this very bug
last month.

And so I am greatly dismayed by the position Russ and Bdale have taken in
this discussion with respect to packages being allowed to depend on a
specific init system.  Both have expressed the opinion that Debian should
remain open to alternative init implementations as long as there are
developers willing to do the work; but when it comes to concrete examples of
ways in which conflation between init system (that is, service registration
and service management) interfaces and dbus service interfaces directly
interfere with that goal, they have been unwilling to stand up for the
relevant technical principle.  This despite the fact that the burden on the
GNOME maintainers to support alternate implementations of these dbus
services is much lower than the burden of providing sysvinit startup
compatibility in jessie for an upstream project that doesn't support it.

As Philipp Kern points out in
<41b26b373019ab39ebff223603a085d1@hub.kern.lc>, this leaves us with the very
real possibility that we will wind up with mutually incompatible sets of
packages in the archive for jessie that are no longer coinstallable, not
because the packages themselves have conflicting functionality, but because
they've taken sides - intentionally or unintentionally - on the init system
question.  If we don't think such fragmentation of the Debian archive is an
acceptable outcome (and I for one don't see any reason it should be), then
we should say as much in our resolution.  The committee has a duty to
provide strong technical guidance to the project, not just to get involved
after something has gone off the rails.

If we *aren't* going to provide such technical guidance about how we expect
multiple init systems to coexist in the archive, then we should not pay lip
service to the idea of supporting multiple init systems and should instead
explicitly declare that only one init system is supported.

Thus, for me, all of the "T" variants in Ian's latest draft
(<21226.41292.366504.997315@chiark.greenend.org.uk>) rank below FD.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: