On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote: > >> Rather, we're talking about whether or not to swap out a core component > >> of an existing integrated ecosystem with a component that we like > >> better. > > Unless you are proposing to make systemd mandatory for all Debian > > installations, this is work that needs to be done anyway. > What I'm hearing from both GNOME and KDE maintainers is that assuming > systemd would save them a great deal of work. I think having systemd be > the only supported and tested option for at least some large package sets > that heavily use the systemd infrastructure upstream is a not-unlikely > long-term outcome. It's clear that being able to assume availability of certain dbus services is labor-saving for GNOME and KDE upstreams, and I see no reason for them not to standardize on such a requirement assuming the dbus services have sane APIs (which they do). What I object to is referring to this as "assuming systemd". They are systemd APIs, sure, but with one exception the systemd implementations are not presently tied to the use of systemd as init, and there is an alternate implementation of that one exception (systemd-shim). 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'm sure there are GNOME upstream contributors who would be happy to see GNOME become systemd-only. But I think their motivations in letting the lines be blurred in such a way are purely political, not technical; and I give GNOME upstream as a whole the benefit of the doubt that they would not so weaken their project to suit someone's political agenda. > 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? You've said that you think the portability question doesn't weight strongly in favor of either upstart or systemd, because neither port is done yet. But the amount of work that would be involved in porting systemd to kfreebsd is an order of magnitude greater than the work involved in porting upstart. logind is just one small component of systemd, which someone could provide an API-compatible implementation for without having to contend with the question of cgroups on non-Linux kernels. If even that is out of reach for the Debian porters, how could we ever expect a full BSD port of systemd to materialize? I think the reality is that adopting systemd as default init for Debian is nothing short of a death sentence for the non-Linux ports. The move to a different init will have a snowball effect in the distribution, as packages stop being tested with sysvinit and popular support grows for dropping compatibility with sysvinit altogether. This is not a problem if the ports are in a position to come along on this transition with a moderate investment in porting init. But the porting required for systemd as a whole is far from moderate, and I believe that faced with such a requirement the non-Linux ports would wither and die. I know there are Debian developers (including many in the GNOME/systemd "camp") who think this is a desirable outcome. I have no personal attachment to the non-Linux ports, but I do think that as an existing part of our Debian community, the TC should at least give these ports a fighting chance, because this kind of competition is healthy. > > My understanding was that Dimitri had got upstart running on BSD. > The latest that I have seen on this porting effort is here: > http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html > I asked previously on this bug if someone had later news. Do you have > more information than that? > The above is definitely not "upstart running on BSD." That's upstart's > underlying support library mostly working on BSD after disabling two > features (that are required for upstart). I haven't not heard whether the > porting of upstart proper has started. That will certainly be much easier > once libnih is ported, but there are, for example, direct uses of epoll in > upstart proper. (I don't know if kFreeBSD already has a portability layer > for epoll in terms of kqueue.) AIUI, upstart itself built out of the box once libnih was available, because all the portability issues are encapsulated in libnih. (The single use of epoll in the upstart source is in the upstart-socket-bridge, which is an optional component from upstart's perspective and certainly not needed for booting a Debian base system - so presumably Dimitri just built with this bridge disabled.) With libinotify-kqueue (that Dimitri maintains), kfreebsd 10 (in experimental), eglibc 2.18 (also in experimental), and Dimitri's branch of libnih, it seems that all the portability requirements for upstart are met, except for abstract socket support. There are evidently still some porting problems that aren't detected at build time, because upstart doesn't yet boot on kfreebsd. But all things considered, the port is rather far along. > upstart is a great project, of which its maintainers are deservedly proud. > However, I don't agree that it's better than systemd. My own research > convinced me of the opposite. But putting that aside, my point in that > section is that, given feature parity (and I mean "feature" expansively, > including adaptibility to Debian's needs), we should choose systemd > because it has more project momentum and better existing integration, > which means that we will have to spend less energy on it and will have > more energy to spend on other things. > It's absolutely worth doing our own, better things. What I don't want to > do is our own *worse* things. Or, for that matter, our own equivalent > things, when we could instead use work that already exists. It's a waste > of energy. I think this downplays the significance of the integration work that has already been done in Ubuntu on top of upstart, that Debian will be able to adopt as-is (or with whatever bugfixes the maintainers find along the way). My look at Fedora 20 confirmed my belief that the integration necessary to have a robust systemd boot across all the configurations that Debian supports has not actually been done yet. systemd upstream advocates shipping systemd units upstream where they can be consumed unmodified by distributions, but in practice Debian is going to be on the hook for debugging the very long tail of integration problems. It's hard to gauge whether the energy saved by not bringing upstart up to feature parity outweighs the energy spent on bringing systemd integration up to snuff, but I definitely don't think there's a clear point here in systemd's favor. -- 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