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

Re: anticipating the upstart migration

Henrique de Moraes Holschuh wrote:
> On Mon, 09 Oct 2006, Gabor Gombas wrote:
>> On Sun, Oct 08, 2006 at 10:53:39PM -0300, Henrique de Moraes Holschuh wrote:
>>> No wrappers for the single most critical binary in a Unix system after the
>>> libc.  Sorry.
>> Right. How about upstart not providing a /sbin/init binary at all, but
>> instead using an "init=/sbin/upstart" boot parameter? The other binaries
> That may be ugly, but it is safe if done right.  I would have little
> against it as a stopgap measure for Etch/Etch+1.

Having the "init" binary installed as /sbin/upstart and only diverting
the not so critical binaries seems to be the safest option indeed.
The only problem I see, is that someone might forget to update
/boot/grub/menu.lst (or lilo.conf) and set init=/sbin/upstart.
I could use a debconf message and/or provide a README.Debian, but people
are known to ignore such hints. This would mean, people would boot into
a system with a mix of upstart's support binaries and init from sysvinit.
As I want to avoid this potential problem, I think it's best, if upstart
simply diverts all conflicting binaries from sysvinit. The only critical
timespan will be between preinst and the upstart package being unpacked.
This risk is acceptable to some extent, especially as you'd still be
able to boot with init=/sbin/init.sysvinit, should the machine crash in

So, with all the concerns raised so far, I'd propose the following:

1.) Remove "Conflicts/Replaces: sysvinit" from the upstart package.
Divert all conflicting binaries from sysvinit and upload the package to
experimental to give it some wider testing first.
2.) If no major problems are found, upload it to unstable after some
time (weeks/months?).
3.) In the meantime work on a solution for the sysvinit-being-essential
problem. Either by introducing a new essential package or through other
means. This would happen after etch is released.
4.) Upload a version of upstart which removes the diversions again [*]
and replaces sysvinit (meaning, sysvinit is uninstalled upon
installation of upstart)

Does that sound like an acceptable plan?


[*] How can I get rid of a diversion again cleanly, without having to
carry preinst around forever with something like:

if dpkg --compare-versions $old_version lt $version_without_diversions;

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: