Re: Proposal - preserve freedom of choice of init systems
Matthew Vernon <matthew@debian.org> writes:
> I wish to propose the following general resolution, and hereby call for
> seconds. I don't think further lengthy discussion of the issues is
> likely to be productive, and therefore hope we can bring this swiftly to
> a vote so that the project can state its mind on this important
> issue. The substantive text is that which was drafted for the purposes
> of the technical committee's vote (where they decided not to pass a
> resolution on the subject).
I sent this just now to the TC bug in response to a message from Colin,
but since this GR conversation has started, it's probably more useful here
instead.
In general, the TC has spent months talking about this, and I've said
rather more than my fair share on the topic, so I would rather let the
rest of the project have their turn and largely stay out of this GR
debate. But I'm not sure that I ever coherently presented, in a single
message, my core argument against the text that Matthew has now proposed
as a GR. That's what this message is. I'm happy to discuss it,
particularly to clarify. I'm going to try to limit my involvement in the
other branches of the debate, in part because I'm a bit burned out on the
whole conversation and in part because I think I've already said my peace.
Since, in my opinion, this question is all about how the project wants to
govern itself and how we want to handle assigning responsibility for work
that we think should happen, I will be very interested in general project
discussion and, if there are enough seconds, voting on this topic. It's
possible that my impression of how the project should work is at odds with
the project as a whole, which would be a valuable course correction for
me.
Anyway, here it is, with a few minor edits upon re-reading it:
I want to reiterate here, since it's easy to lose in the long discussions,
that I completely agree with the sentiment. I like the idea of
standardized services and interfaces, I like having the flexibility of
multiple implementations of those services and use that flexibility quite
a bit myself. I would generally prefer for multiple implementations to be
possible in any case where there are multiple ways of going about
something.
However, I also don't think those principles were ever what this debate
was about. I don't think we'll find much disagreement with those as
general principles.
The question that is before us is not whether we approve of standard
interfaces and multiple implementations. Everyone who has spoken up on
this topic has indicated support for allowing multiple implementations of
standard interfaces. Rather, the question that was before us was about
the error case. When circumstances arise where those multiple
implementations do not exist, who bears the burden of creating them?
The position of loose coupling is that the Debian contributor who wants to
package a piece of software is responsible for porting it to every major
init system.
The position for which I was advocating is that the people who are
interested in having software run on the non-default init system, which
*may* include the Debian contributor who is packaging it but *might not*,
are responsible for the porting work, and that packaging of the software
for Debian should not necessarily block on that work being completed.
In other words, I'm advocating the same position that we have right now
for translations: the package maintainer is not expected to translate
their package to other languages, but they are expected to incorporate
translations as they are made available. The translators bear the burden
of the work for doing the translation, and if no one steps up to translate
a particular package to some language, it won't be available in that
language.
To take the specific example of GNOME, in a world in which there are
multiple implementations of logind that satisfy the same interface, there
is no conflict here. I want to keep reiterating that, since it seems like
people keep thinking they're at war with others when no actual conflict
exists. The GNOME maintainers have already said they'd be happy to allow
alternative dependencies, the systemd maintainers have already said they'd
be happy to work with the providers of alternative logind implementations
to sort out the proper dependency and package structure, GNOME upstream
has said that they'd be delighted for such a thing to exist, and everyone
would be happy to have this in place by jessie. We're all a big happy
family on this point, even if some of the people in the back seat can't
stop poking each other. :)
*All* of this argument is over what happens when those multiple
implementations don't actually materialize.
My continued objections to loose coupling is that I think it makes the
wrong choice in that contingency, and I think it does so in a way that's
destructive to Debian as a project. I believe the loose coupling proposal
has the effect of trying to force Debian contributors to care about
something they don't necessarily care about as the bar to entry in the
project.
Now, that is appropriate to some extent, since the goal of Debian is to
create a distribution, not a random collection of packages. But
historically (and this line is what Policy is *all about*, so I've had a
lot of practical experience with it), we've tried to limit the places
where we make this sort of requirement to two types of problems: places
where the package simply has to work a particular way or it won't be
functional or may break the rest of the system, and places where the
amount of effort required for the maintainer is reasonably small. So, for
example, if you package a shared library, you have to care about shlibs or
symbols, SONAMEs, and library package naming. That's just the way it is;
we rely on those mechanisms to make shared libraries work properly, and
your package is broken and will break other things if you don't follow
those rules. Or, for the second point, your package should not strip
binaries if DEB_BUILD_OPTIONS=nostrip is set. This is generally quite
easy to do, and normally the standard tools do it for you, so there aren't
a lot of good reasons for not supporting this.
Porting GNOME to something other than logind, or implementing logind
without its various systemd requirements, is neither of these things.
It's not something that has to be done or the packages are simply broken,
as demonstrated by the fact that they would work fine with the default
init system (which was, at least as far as I'm concerned, chosen for
different reasons than this whole argument). And it's not a small amount
of work.
If people do the work, great! Everyone thinks that's great, as noted
above. We define a virtual package that provides the necessary
interfaces, multiple maintenance teams happily maintain multiple
implementations going forward, and we move on with our lives. We all hope
that's the situation that we end up in.
But when providing project-wide guidance, we have an obligation to worry
about the error conditions as well. If multiple logind implementations do
*not* materialize, or if they do materialize but then people lose interest
or run out of time and stop maintaining them and they stop being viable,
loose coupling says that the burden now falls on the GNOME package
maintainers to do all the work to write or maintain an alternative logind
implementation. For init systems they don't use or for systems they don't
use.
That's not cooperation and coordination and working together. That's
holding someone's work hostage to try to force them to do (substantial)
work that they're not interested in. I think it's directly contrary to
the spirit of section 2.1.1 of the constitution, and it makes me very
unhappy.
We all want there to be multiple implementations of standard, reasonable
APIs so that we can choose software based on its merits and not because
it's the only implementation of a useful interface. We also all live in
the real world where that doesn't always happen. The work doesn't
magically accomplish itself. Someone has to care enough to make it
happen. If no one cares enough, then I think we need to recognize that
maybe having multiple implementations isn't important enough to motivate
anyone to volunteer to do it, and therefore we'll have to live without the
benefits of having them.
If that feels like an unacceptable outcome, well, I think the right
reaction is to go do the work so that this outcome doesn't arise. Not to
try to write project rules to force other people who are less interested
in the work or who may not agree with the acceptability of the outcome to
do the work on our behalf.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: