On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > From comments made by various GNOME upstream developers on this, I think > > they are being suitably cautious about avoiding scope creep where the > > systemd dependencies are concerned. So in what sense are the GNOME and > > KDE requirements not already being met on top of upstart? The only > > outstanding issue I see is with non-Linux ports, because logind is not > > portable; that's definitely a problem for running GNOME on kfreebsd, but > > it's actually a rather narrowly-scoped porting problem and one that the > > ports need to deal with one way or another if they want GNOME to > > continue working. > I don't see what you're saying here as substantively different than what I > said in my writeup about the ecosystem. I feel like we're both presenting > the same facts through different lenses. I do see a substantive difference between "GNOME depends on systemd" and "GNOME depends on interfaces a, b, and c, which are available as part of systemd". > >> One can, of course, have a wide variety of reactions to that. As > >> someone who considers portability to be an inherent good, I find it > >> sad, although I don't have a full appreciation for what problems GNOME > >> is trying to solve by increasing its reliance on systemd. But I'm > >> highly dubious that Debian will just single-handedly fix that, or that > >> we would drop GNOME because we don't like upstream's integration > >> decisions. > > I find the notion that Debian doing this "single-handedly" is an > > obstacle to be a bizarre one. Debian has more than one pair of hands, > > it's a veritable multi-tentacled beast. Have we so atrophied as a > > community that we'll wail and gnash our teeth about a non-portable > > dependency, but have no porters willing to actually provide a native > > implementation of a (quite small) dbus API? > Please recall the context here: this whole aside started with an objection > to my contention that adopting upstart requires disassembly and redoing of > an integration that we would otherwise not have to disassemble. Nowhere > in my message did I say that we would or could not do that disassembly if > we adopted upstart; I said that it was work that we otherwise wouldn't > have to do. > That's the intended context of my point above: I don't think we're going > to port GNOME to a non-systemd infrastructure, in the sense of carrying > significant patches to GNOME to adopt it to, say, not using logind. I > think GNOME will continue to use systemd APIs heavily, which makes GNOME > less portable. That means that systems that are not capable of running > those systemd components will need to either port them or develop > alternatives. > I don't consider this wailing or gnashing of teeth, but rather a realistic > look at what efforts the project is talking about committing to, as > opposed to supporting people working on if they so choose. Ok. I think our core point of disagreement here, then, is in our assessment of how much work we think this actually is (for the Linux case, not for the non-Linux case). I think the actual package maintenance to make this happen is not even a weekend's worth of free time, and therefore represents a negligible committment of resources on Debian's part, given that this dissassembly/integration has already been done in Ubuntu. > *If* Debian adopts systemd as an init system, I do think that it's > possible (how likely, I don't know) we'll end up with GNOME unavailable on > the kFreeBSD port because people choose not to do the effort of separating > out and porting the components required. It's up to the porters, and > depends on what role they see for the port. If, for example, they're > primarily targeting servers, this may not be a significant loss. The > point is that it would be their call. Right. I think that if we adopt systemd, GNOME will be the least of the kfreebsd porters' problems, because of the overarching init integration questions. > My belief, and again I welcome concrete reasons why I'm not correct, is > that adopting upstart poses a similar risk for the Hurd port as adopting > systemd, and I care just as much about the Hurd port as kFreeBSD. Well, certainly there is risk that no one will be interested in doing the work to port libnih+upstart to the Hurd. Picking either upstart or systemd will not guarantee that we have porters willing to do the work to keep up. But I think the success of the in-progress kfreebsd port shows that upstart poses a much lower portability barrier than systemd; if we want non-Linux ports to exist on the same terms as the Linux ones (i.e., without needing backwards-compatibility solution for sysvinit), I think upstart does give them a much better fighting chance. > I want to mention again something that you'd dismissed as possibly a joke > earlier, but which I was actually serious about: I think a world in which > we use systemd on Linux and upstart on non-Linux ports, should upstart > prove much more portable, actually makes sense. As I said in my other > writeup, I believe the systemd feature advantage is sufficient to choose > systemd in isolation, without the other issues discussed. I also believe > that maintaining a systemd unit plus an upstart configuration is, modulo > testing (which I realize is a huge issue), much easier than maintaining a > single sysvinit script. I agree that maintaining a systemd unit plus an upstart job is better than maintaining an init script. I just can't see any way through to a world where these will both actually be maintained (the testing problem), particularly if upstart use is relegated to the non-Linux ports. It's hard for me to view "Ubuntu, Debian GNU, and Debian GNU/kFreeBSD use upstart; Red Hat, Fedora, SuSE, and Debian GNU/Linux use systemd" as anything but a loss for upstart. With only non-Linux ports of Debian on upstart's side and all the other potential collaborators among the traditional distros opting for systemd, I think that would leave Canonical confronting some hard questions about whether to continue investing in upstart development. Earlier in the discussion, you posited that the same argument for Canonical deinvesting in bzr could be applied to upstart: >> bzr lost the DVCS war not because Canonical was unwilling to invest in >> bzr, but because git had an early lead in performance and flexibility >> that made it the runaway choice for developers, and by the time bzr was >> catching up in functionality, network effects meant it was too late. >> Once it became clear that bzr would not deliver on its promise of being >> a universal DVCS because the world had already adopted git as a de facto >> standard, it was reasonable for Canonical to stop investing in bzr >> development. > True. However, I'll point out that a similar argument can be made for > systemd. My answer to this is that, as things stand today, this argument does *not* apply, because Debian hasn't made a choice for either systemd or upstart yet. Whichever option Debian chooses, that is the option that is going to carry the day, because Debian does integration better, and across a wider range of software, than any other distro out there. If Debian chooses systemd, then these integration efforts become focused on systemd, and systemd wins. If Debian chooses upstart, then upstart wins. And if Debian chooses upstart only for the non-Linux ports (which attract the attention of only a small minority of Debian developers), then systemd wins - and any spare cycles Ubuntu might win back by having Debian and Ubuntu in alignment on init systems go out the window, leaving less time to invest in upstart development. So I don't think I would vote "systemd on linux, upstart on non-linux" above "systemd, non-linux ports to figure out how to be compatible", because I fear that would be leading the non-Linux ports on. I don't think it's fair to them to recommend upstart as a path forward when upstart's own future would be uncertain under such circumstances, on top of them already having to shoulder the burden of doing all the testing of upstart jobs that are used nowhere else in Debian. (As a personal aside, whichever of upstart and systemd is chosen by the TC as the default, I intend to wholeheartedly adopt it for my own use in Debian. I love the upstart codebase, for all the same reasons that you found when you looked at it, but I'm not on a quixotic quest here. If Debian chooses systemd, then any time I spend on debugging init system bugs in Debian is best spent debugging them on systemd, where it will bring the most benefit to our users.) Cheers, -- 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