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

Re: anticipating the upstart migration



On Fri, Oct 06, 2006 at 10:43:00PM +0200, 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.

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

> Comments? Unless there's fierce opposition, I strongly suggest we
> carry through with this.

As enthusiastic as I am about being able to replace sysvinit with something
better, this is the wrong time in the release cycle to be making dependency
changes to Essential, or even to the base system in general.  I certainly
don't expect to be willing to grant a freeze exception for a non-Essential
sysvinit in etch.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: