Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Steve,
On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> > Having read the parts of the ctte bug, it feels odd to preclude the
> > option of supporting multiple init systems from discussion or
> > consideration. If Debian is to support only one init system and that one
> > init system is systemd, then given my above analysis it will be very
> > hard for non-Linux ports to catch up. I argue that in this case we
> > should consider dropping support for non-Linux ports. So if we really
> > are considering such an outcome, why not consider the outcome of
> > supporting multiple init systems (but maybe only one per architecture)?
>
> While other members of the TC may wish to consider this option, I've ruled
> it out myself because we would lose most of the benefits of switching away
> from sysvinit and instead accrue significant maintenance costs to individual
> developers who would then have to support both init systems in their
> packages. What makes switching init systems worth doing is being able to
> *simplify* the interfaces between the init system and the services.
> Continuing to support different init systems across different architectures
> would add complexity instead. That's a pretty bleak outcome.
I fully agree with your reasoning. Yet, I see that the options
* drop support for non-Linux ports and
* maintain some support for an alternate init system
are similarly painful. I see neither of them a desirable, but if we
really consider one of them, I'd ask for the other one to be considered
and evaluated as well.
Most participants in this thread appear to agree that the sysvinit
*interface* for services (shell scripts) is suboptimal. We are currently
mostly arguing about implementations, because each proposed interface
has only one implementation. It might make sense to consider a subset of
the interface that one implementation provides as our standard and
provide a degraded experience to that interface on non-Linux ports. For
example, if systemd were to be the init system of choice, it could be
required to provide an init script for services with Type=notify.
The interfaces of all init systems (except sysvinit, but are we really
considering that one?) still are somewhat in flux, so this is the point
where we can still influence and shape them.
<dream>
Imagine a world where upstart and systemd would use the same syntax
(structure) but implement different and somewhat overlapping aspects.
Maybe 50% of the daemons would work with either of them without needing
changes. <wakeup/> But now we call it "exec" here and "ExecStart" there,
"export" here and "Environment" there, and "chdir" here and
"WorkingDirectory" there. Bummer.
</dream>
Oh wait, I am talking to one of the guys who can actually fix this. :)
> > This would become radically easier if gnome were to become Architecture:
> > linux-any.
>
> GNOME may be the trigger for this being raised to the TC, but it's not the
> core question that we need to address.
Even though I did mention gnome over there, the argument is not
restricted to gnome in any way. It can be applied to any other package
not deemed worthy to support on non-Linux ports (and I should have made
this explicit). Furthering this thought leads to turning non-Linux ports
into derivatives as presented by others in this thread.
I argue that a resolution of this bug needs to answer:
What is going to happen with non-Linux ports?
Helmut
Reply to: