On Mon, Dec 30, 2013 at 3:30 PM, Steve Langasek <vor...@debian.org>
wrote:
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?
systemd lists logind as non-reimplementable, and that was pretty much
proven when Ubuntu tried to reimplement it and ended up reimplementing
or pulling in a ton of systemd anyway. Seeing that, both KWin and
Mutter have denounced portability to non-Linux when running on Wayland.
They will soon be outright non-portable (when ConsoleKit support is
dropped, which, AFAIK, is soon in GNOME).
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/
slanga...@ubuntu.com
vor...@debian.org
