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

Re: GR: Selecting the default init system for Debian



Le Thu, Jan 23, 2014 at 04:14:41AM +0100, Wouter Verhelst a écrit :
> On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote:
> > In that case, I think that the project should decide via using this or that
> > system (“vote with the feet”).  For the packages where init scripts are a
> > limitation, just depend on systemd, upstart, openrc, or combinations of them,
> > and if and only if it is not possible to install Debian because pairs of core
> > packages depend on different single init systems, let's vote.
> 
> So, let me get this straight.

Hi Wouter,

OK, let's be straight :)

> You're saying "let's do nothing until the entire system breaks because
> of a component that nobody really cares about, so that we can _then_ try
> to start a procedure which will take weeks (if not months) to maybe
> unbreak it, leaving the system in an utterly broken state in the
> meantime?"

What I am saying is:

Let's allow the Debian system to evolve freely: the result will not be
breakage, but systemd as a de facto default.

If some parts of the system become mutually exclusive, I do not see it as
problematic.  We do not support the co-installation of some mail or FTP servers
packages even though in theory one can configure them to listen on different
ports; if tomorrow one desktop manager depends on upstart and another on
systemd, then the solution is to call this unsupported as well.  I would also
argue the same if it were web browsers.

I would call a system broken if it would not be possible to do anything useful
with any of the init systems.  I do not see how this could happen.  First,
these init systems are developed and tested on computers that run them, such as
Fedora, Ubuntu and Gentoo, which shows that there is no critical missing piece
in one or the other system in the context where they are intended for.  Second,
at least systemd runs fine on Debian currently, and to my knowledge, there are
no core components that are likely to drop systemd support in the near future.

Then, there is the fear that because systemd or upstart is much easier to
support than our current init system, the non-Linux architectures that can not
run them will dissapear because init scripts will be dropped massively.  To me
it is a total overstatement.  What is at stakes is whether these ports will
benefit as much as before from the work on mainstream systems such as Linux on
amd64.  The answer with is “no”, unless we enforce a default with this goal in
mind, that will cost to others what it gains to the non-Linux architectures.
But that “no” does not make these projects impossible.  At worse, it will force
them to focus on their userbase instead of working on total coverage of the
Debian package supermaket, and I think is would actually be a good change
(please do not waste your time sending patches to leaf packages until you know
that somebody is actually planning to use them on your port).

Lastly, there is the political part.  Should we boycott systemd or upstart ?
Should we make choices that in practice mean to show the door to our GNOME
team ?  Should we push even more our contributors to participate to the porting
on specialised architectures ?  Let's releive the technical comittee from the
pressure to step in that field.  The best reaction to these questions is to
ignore them.

So definitely, thanks Steve and the sysinit maintainers for making transition
between init systems easier; with this I do not think that we need a decision
on a default system anymore.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


Reply to: