Colin Watson <cjwat...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
