Bug#727708: init system other points, and conclusion
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.
> On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
>> 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.
> 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.
I haven't investigated this myself, but that matches the impressions I've
gotten from discussion both here and in Lennart's blog. Nothing I'm
writing here is intended as disagreement with this point. Porting systemd
looks harder.
> 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.
Yes, as I said explicitly in my writeup, it may well be the case that
porting some of the components of systemd will be substantially easier
than porting the init system.
> 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 never said that a port of logind was out of reach for Debian porters.
I'm saying that there's a lot of work here, and we don't yet know whether
or how any of it is going to happen. We should not close off possible
future directions unnecesarily, but we need to make a decision based on
the current state without assuming that roadmaps will necessarily come to
fruition.
*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.
If Debian adopts upstart, obviously we're going to be required to do the
work of separating the init system from the rest of systemd, which will
make some of that effort possibly easier for the kFreeBSD porters
(although that work will not magically port logind to kFreeBSD, or adjust
for any future requirements for D-Bus that might materialize, etc.).
Either way, real effort will be required to get GNOME working on
kFreeBSD. I'm not saying that effort won't happen. I'm saying that we
have choices about what effort we're going to *commit* to, as opposed to
leaving to the discretion of the porters, and that I am dubious of this
argument that going with upstart as the init system makes that work
substantially easier.
> 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.
This is definitely something that might happen. It's a risk of the
approach that I outline. I'm less pessmistic than you are about it, but
this is definitely a risk.
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. And
while kFreeBSD is in better shape due to the already-begun upstart port,
there are still significant porting challenges in the way of maintaining
feature parity in the kFreeBSD port at the level that it has today. Many
of those challenges are going to remain regardless of which init system we
pick.
> 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.
Well, I won't get into how much I loathe the word competition in this
context, but as you can see from my other message this morning, I'm in
wholehearted agreement with giving the ports a fighting chance.
> 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.
Thank you for the update! It sounds like it's farther along than the
previous information I had, although not as far along as Ian had thought.
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 do want to reiterate here, though, that my position on transitions,
multiple init system support, and so forth are exactly the same if upstart
works on kFreeBSD but not on Hurd as if it works on both of them. I
consider them to have equal place here. (However, demonstrated
portability to kFreeBSD may -- to what extent I don't know -- indicate
that the port to Hurd will be relatively easy.)
> 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.
I believe the level of features that systemd brings to the table is
substantially beyond what's available from upstart at the current time,
and am confident that, even including the level of effort required to
integrate systemd without the work that Ubuntu has done for upstart, we
will end up ahead on the Linux ports. My defense of that position is
basically the sum total of my previous two messages, so I won't repeat it,
just note that you have correctly identified a core disagreement between
the two of us.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: