Hi together,
first of all, sorry for being so late to this party.
I'll start with describing a few facts, observations and thoughts, and come
to my conclusions at the end of this mail. I don't write references at
places where I believe had already sufficient coverage by others and/or are
more or less not really doubted. I also didn't write at all possible
required locations as far as reasonable or similar - I assume and expect
that we all try to integrate our system as good as reasonably possible
without wasting too much time for details nobody cares about, and I didn't
want to write it at all places again and again. (And just because something
is technically possible doesn't mean it is reasonable possible, and if I
write possible below it refers to reasonable possible, and same with
similar words.) Also I try to not repeat too much of what had already been
written by others, especially in other summaries.
What are we speaking about? There are three different things: The
pid1-provider, means: what is init in the terms of the linux command line
(current default: sysvinit). Then the runlevel-manager (current default:
sysv-rc). And then a daemon which could start and stop other services
(which is always provided by the pid1-provider, but there are other in
Debian, and as long as they could be used at the same time together, I
don't think there is any conflict, and so no reason for a decision).
Also, as discussion has shown, we speak about what is default in Debian
(please note that this could be more than one overall, so it might be
defaults in Debian). Then, what is required to be supported (at least
what is default anywhere on a architecture in testing). And then what else
are maintainers supposed to support on an higher than wishlist level.
State of the different init systems: First of all, I think that all three
contenders are better than our current state. Systemd and upstart are way
better, openrc still is a major improvement about sysv-rc. So all three are
in the game for me.
I however don't believe that we could realistically support all three
(four) equally good at the same time. It might had worked if somebody would
have found a clever meta-format that could be autoconverted by debhelper in
almost all cases, but as none is there yet I doubt it's realistic. It might
work that we support two of them at the same time, but even that is a bit
painful for us (and there should probably be some autotesting then as
suggested by Anthony recently).
So, what could realistically work:
On the linux ports, all would work. On the kbsd ports I believe that both
upstart and openrc could be working, but none is yet. For hurd, at least
openrc could and probably also upstart.
Porting systemd to kbsd or hurd is not realistic from what I understood
(unless they basically clone the linux cgroups feature), but a parallel
implementation of programm with similar configuration files would be
possible (but I don't believe in that, especially for the long-term
maintenance[1]). Porting upstart seems to be possible, but has the CLA-issue
which makes flowing patches back to upstream harder (and therefor I would
recommend Canonical to not use this policy for upstart), so we would have
to carry extra patches within Debian (which however doesn't look as painful
as a parallel implementation of systemd). Openrc looks like it could work
in the upstream way everywhere, but needs a bit of porting.
I don't believe that it would work long-term if we use systemd on Linux and
upstart on !Linux.
[1] Having a parallel implementation of systemd for kbsd would mean that we
also need to take care that e.g. logind is useable without systemd. Which
however means that we'll have the same work required to use non-systemd as
default on Linux plus some additional work for the systemd-mimikri. Doesn't
sound too attractive to me.
All of that together boils down to these options for the default
pid1-provider / runlevel manager (perhaps after some more porting in this
cycle):
1. Systemd on Linux, openrc/sysv-rc on non-Linux
2. Upstart everywhere
(3. openrc/sysv-rc everywhere - as both systemd and upstart are better, I don't
think this ends high enough on my priority list; see below for details)
What does required to be supported mean? Basically the same as always -
the basic functionality needs to be good useable, and everything else
reasonable supportable as well. And any required to be supported provider
needs to be supported at least to the same amount as any other. This
doesn't mean that functionality needs to re-invented just because it is
technically possible. To take an example from a recent irc conversation, I
don't think it's sensible to expect people to do multi-instance setup in
sysv-rc just because it is technically possible (but extremly painful) and
it is done in (systemd or upstart), but on the other hand, if systemd would
be the default and sysv-rc not anymore and someone does multi-instance in
sysv-rc I would expect