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

Re: supporting alternative init systems

Hi martin,
hi fellow DDs!

I really support the idea martin is proposing but I want to see it in a
broader scope, not restricted to upstart alone (although I'm very
interested in upstart). Currently our support for alternative init
systems (like upstart, minit, runit, initng, to name a few) sucks resp.
is nonexistent. I'd like to see a better infrastructure which enables to
switch to another system without problems (very much like it's today
possible to choose your preferred inetd, mta etc.). So I'm going to
outline some ideas I've been thinking about how this could be done and
I'd be happy to hear comments.

martin f krafft wrote:
> upstart is looking interesting and it might just as well replace
> sysvinit for etch+1. Or at least be an alternative.
> In order to enable this change, we're facing the "To continue type
> in the phrase 'Yes, do as I say!'" problem because sysvinit is
> marked essential.
> Jeroen said this has been discussed previously, but didn't remember
> the outcome. I am strapped for time, so I did not bother reading the
> archives as I did not find the discussion during a cursory look, if
> someone would shove them in my face, I'd appreciate it.
> My suggestion is to add a package "init-daemon" or maybe "pid1" to
> etch, which is essential and depends on sysvinit. Then, make
> sysvinit non-essential.

I already proposed a similar approach in [1].
My idea was to introduce a new package, let's call it "init" for now,
which has priority required and is marked essential. This package would
depend on "sysvinit | init-system", where init-system is a virtual
package. This init package will also contain some common infrastructure,
which I will describe in detail later.
When that package exists, the Essential flags would be removed from
sysvinit and sysvinit-utils; in addition sysvinit would add a
"Conflicts/Replaces/Provides: init-system" (sysvinit beeing the package
that ships /sbin/init).

The advantage of depending on a virtual package called "init-system"
would be, that we wouldn't have to change the "init" package, each time
a new init system was added to the archive. It would be up the the new
init system package to declare "Conflicts/Replaces/Provides: init-system".

We could also switch the default init system easily for etch+n by
replacing "sysvinit | init-system" with "foo | init-system" in the init
package. New installations would then automatically get the new init
system, existing installations could decide to upgrade or keep the old
resp. the preferred one.

I'd really like to see that happen for etch, because it would make the
upgrade for etch+1 (if we decided to switch) easier.

> If we have that in etch, migrating to upstart (or just enabling it)
> would be as easy as making the dependency "sysvinit | upstart".
> I realise this will be hard to do at this stage, but not impossible.
> But thinking ahead, I think we'll save ourselves quite some trouble
> later.


> < jvw> this really is a very very bad time for introducing a new
>        essential package
> < jvw> d-i, debootstrap, etc etc
>  * madduck pretends to not have heard that last comment by jvw
> < jvw> madduck: should I repeat it?
> < madduck> jvw: nooooo
> The alternative:
> < jvw> anyway, the only viable solution I see that gets both
>        no-new-base-packages *and* a non-essential sysvinit so
>        upstart can be installable without apt croaking in etch+1 is
>        having another currently essential package depend on sysvinit
>        | some-init-daemon-virtual-package
> I would consider this a hack, but it might be the best option, and
> it should allow us to migrate to my above suggestion for etch+1

While having a currently essential package having a "Depends: sysvinit |
init-system" is surely easier to accomplish and better than doing
nothing at all for etch, I think we need a separate "init" package
sooner or later to provide a common infrastructure, our packages are
expecting, mainly this is update-rc.d and invoke-rc.d which are called
in the package maintainer scripts.
"init" would provide the two binaries
/usr/bin/(update-rc.d|invoke-rc.d), which would be small wrappers
calling the actual scripts in /etc/init/invoke-rc.d/ and
/etc/init/update-rc.d/ via e.g. run-parts.
The sysvinit package (or better sysv-rc), which currently provides
update-rc.d/invoke-rc.d, would move its scripts to /etc/init/*.d/.
An alternative init system could implement and provide
invoke-rc.d/update-rc.d by installing scripts into /etc/init/*.d/.

Currently packages like apache, exim, dbus etc. provide sysv-style init
script. A new init system would have to provide it's own implementation
of this startup jobs (well, maybe not for all of them, but for the most
important ones), and make sure, that update-rc.d installs the correct,
corresponding alternative. The calls to invoke-rc.d should be translated
to corresponding calls, e.g. for initng an "invoke-rc.d start apache2"
would translate to "ngc -u apache2". For other systems it could be a
noop or something else.

This is definitely etch+1 or even etch+2 material, but I think we should
set the right course now.

As new co-maintainer of upstart I'm willing to work on this but I want
to hear your opinions first. If there is agreement on this plan, we
could work out a timeline and a more detailed specification.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385722
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: