iniTscripts: followup
(yes, I know how to type, but my keyboard is degrading. Apparently, I didn't know how to read yesterday)
There were a number of replies to my post about upstart and other init-implementations yesterday. Since it apparently didn't come through properly: yes, I do know about upstart-compat-sysv, and yes, I'm obviously using it. That wasn't the point.
The point is that using upstart-compat-sysv is a workaround which allows to migrate to upstart, rather than to support it in parallel. Debian has always been about choice; giving people the choice to use upstart rather than sysvinit and vice versa is something we should do. Ubuntu has chosen to use upstart rather than sysvinit, and that's their prerogative; but Debian as a whole cannot (and will not) make that choice.
The point of the exercise was to figure out a way to allow people to say "I want upstart", and bang—everything gets migrated to event.d scripts. But if they then decide that they don't like upstart after all, they should be able to just reinstall sysvinit, and bang—everything gets migrated back to regular SysV initscripts.
That currently isn't possible, and upstart-compat-sysv doesn't offer that.
What do sysv initscripts offer that upstart doesn't? In what context would only upstart be a disadvantage? I don't claim to have an answer. I don't even know enough about the question. I do have a remark though.
Configurability is nice, but too much of it - especially at such a low level in the infrastructure - can kill Debian as an otherwise awesome product. Many people would not call that flexibility, but a lack of focus.
I don't know enough about this particular technology, but this probably shows one thing Debian developers are often too afraid to do. Balancing configurability and focus is hard, but it's not impossible at all.
This is something so very important for a DPL to work on...
Debian has always been about choice; giving people the choice to use upstart rather than sysvinit and vice versa is something we should do. Ubuntu has chosen to use upstart rather than sysvinit, and that's their prerogative; but Debian as a whole cannot (and will not) make that choice.
Atm the user has no choice, btw. He only has sysvinit as an option.
If upstart is a complete drop in replacement for sysvinit (which it is in combination with upstart-compat-sysv), but has a much cleaner code base and offers the great potential to significantly improve the boot process by writing native upstart job files, why is it so far off to replace sysvinit with upstart?
While I support your idea of making it possible to switch back and forth between upstart and sysvinit, the only possibility imho is, that packages ship both sysv initscript and native upstart job files. [1]
When upstart is installed, a diverted update-rc.d will make sure, no links in /etc/rc?.d/ are created. In case upstart is uninstalled again, these symlinks will be put back again.
There really is no automated way of transferring a classical sysv initscript to an upstart job file.
[1] I know this touches a lot of packages and will potentially take quite some time because every package maintainer has to fix its package. But as upstart has strong backwards compatibilty support, no package maintainer is forced to do it at once. For the core packages, a la hal, dbus etc, a concerted effort should be possible quite quickly.
The point is, what's the unique value in upstart, as opposed to initng? Or what's the unique value in initng, as opposed to upstart?
Providing alternate init implementations is one thing; giving our users the option to pick the one that fits them best is quite another.
It's Ubuntu's choice not to give their users a choice, but rather to give them a predefined, preconfigured system after installation. This works for them, but trying the same in Debian would not work. We've always given our users a full choice of software: file-rc vs sysvinit, or gnome vs kde, or apache vs apache2 vs boa vs 10
other HTTP daemon implementations. Continuing to do that has nothing to do with focus or lack thereof, but everything with continuing what we've always done and what works for us.
Our users have come to depend on us for that.