[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: init system other points, and conclusion



On 31 December 2013 12:32, Steve Langasek <vorlon@debian.org> wrote:
> 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.

I wonder if folks could clarify what status they expect secondary init
systems to have in Debian?

To me, the above seems similar to saying "I just can't see any way
through to a world where both exim and postfix, or apache and nginx
will both actually be well supported in Debian" -- choosing an MTA or
web server is something we leave up to the sysadmin, even if we choose
defaults at install time, and packages that use their services are
generally expected to work well with whatever the sysadmin chooses.
That's obviously not the case for every package, some provide modules
for apache but not nginx say (libapache2-mod-*), and others are
specifically for postfix and won't work with exim (pmailq, postfwd,
postgrey eg), but packages that just want to call sendmail or provide
a cgi script are expected not to care. Similarly, choosing Gnome as
the default desktop for Debian doesn't mean you can't reasonably use
KDE or XFCE on your Debian system. For postifx/exim and apache/nginx I
don't think you have to have any elements of the other system
installed to run your preferred system; I'm not sure that's so true
for KDE or XFCE though -- certainly I use packages that pull in libgtk
(groff, gnuplot, emacs, evince) and libgnome (inkscape?) on my XFCE
system, for instance.

Maybe this should be different for systemd/upstart -- maybe they're
more like dpkg/rpm or apt/yum -- you can certainly install all four on
your Debian system, but two of them aren't so useful for actually
managing it.

That /seems/ like an undesirable situation though -- certainly it
seems like there are a bunch of people who'd like to run systemd on
Debian, a bunch who'd like to run upstart on Debian (Canonical if no
one else), and at least a few that might like to run something else
(OpenRC users, kfreebsd/Hurd folks). Are the obstacles to supporting
that really infeasible/insurmountable? Wouldn't it be reasonable to do
something like piuparts in EC2 to test packages under different
/sbin/init providers to see if they behave roughly as expected?

(Is it really harder to have upstart and systemd support in Debian
than it is to support running Debian on either a Linux, FreeBSD or
Hurd kernel? All those things are already possible anyway, aren't
they?)

> 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.

(So, uh, that would mean that a Canonical-employed maintainer of
upstart would have a fairly challenging conflict of interest in this
decision, right?)

> 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.

So that's not true of apache/nginx, exim/postfix, or Gnome/KDE. I've
seen some argue recently that it's true for dpkg/rpm, but only
post-Ubuntu -- prior to that I think I only saw that claim in reverse.
It doesn't really strike me as a great argument as a consequence.

> 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 would vote "Gnome on Linux, XFCE/fvwm on non-Linux" over "Gnome on
Linux, non-Linux ports have no desktop until they figure something
out" quite happily. That only works because XFCE/fvwm are entirely
plausible options on Debian with a Linux kernel, though, and only
works well because there are standards for packages to tell desktops
how to add them to their menus.

> (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.)

For comparison:

1771  task-gnome-desktop             35102     0     0     0 35102
(Debian Install System Team)
2460  xfce4                          16800     0     0     0 16800
(Debian Xfce Maintainers)

Personally, I run xfce because it works best for me; I wouldn't give
even a moments thought to running Gnome because by doing so I might
find and fix some bugs that would help other folks. I'd apply the same
argument to systemd/upstart, personally. To me, that seems like the
best way to let the most beneficial technology win out.

It seems to me like "what should the default init system be?" is a
very different question depending on whether other init systems are
also well supported. I get the impression that you think there's not
much chance of other init systems working well, while what I've read
from Russ and Ian seems to indicate that it ought to at least be
feasible. I can certainly understand that multiple init systems isn't
a winning idea from the point of view Ubuntu (or Red Hat) would take
when putting together a distribution, but I would have thought it was
something Debian could/should/would manage.

Forced to make a choice, should Debian go for smoother/tighter
integration between apps, or more choice for users/sysadmins? I'd
expect Debian to choose the latter; though Ubuntu, Red Hat and
possibly Fedora might choose the former.

Cheers,
a "por que no los dos?" j

-- 
Anthony Towns <aj@erisian.com.au>
Not speaking for my employer...


Reply to: