Bug#727708: Call for Votes on init system coupling
Colin Watson <cjwatson@debian.org> writes:
> I ran across this interesting post from an upstream GNOME developer
> which I think deserves some signal-boosting, as I haven't seen much of
> its contents mentioned or alluded to so far in this thread, and it's
> quite relevant to how much we should expect this to be a problem:
> http://blogs.gnome.org/desrt/2014/02/19/on-portability/
> Aside from an anonymous troll (it's a shame everyone even remotely
> involved appears to have to deal with those these days), his comments
> seem to have pretty broad support among the other GNOME developers I
> recognise who've commented.
I want to reiterate here, since it's easy to lose in the long discussions,
that I completely agree with the sentiments here. I like the idea of
standardized services, I like having the flexibility of multiple
implementations of those services and use that flexibility quite a bit
myself, and 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 you'll find much disagreement with those as
general principles.
The question that was before us, and which is now likely to be before the
project as a GR, is not whether we approve of standard interfaces and
multiple implementations. Everyone, from the GNOME upstream to the GNOME
package maintainers through the systemd maintainers, 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, who
*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
attempts 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.
The project that would assign work in that way is not the sort of project
that I want to be part of. 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: