There is a lot of feelings and temper involved in the current discussion of init implementations in Debian. I'd like to try to de-escalate by summarizing things in as objective and non-confrontational manner as I can.
* sysvinit is mostly working for everyone, but it has problems, in part caused by changes in the kernel over the years. See [1] by Petter. It's not even primarily about boot speed, but about reliability, especially in the early boot. * It's also the case that our init.d scripts are full of repetitive code, often subtly different, and similar bugs happen independently in many places. If we stay with sysvinit, we need to fix this. * Event based init systems attempt to provide other things too, including faster boot speed, and an overall simpler, faster, leaner, and more reliable system. * The two main event based contenders are upstart and sysvinit. Both are written for Linux, and rely on various Linux specific kernel features. They have some technical and other differences, and have upstream developers who can be considered controversial in various ways by various people in Debian. However, both are, of course, free software, and both should work acceptably well as an init in the Linux version of Debian. * We can choose to stay with sysvinit, but then we'll need to start developing it to be more suitable for modern Linux. * We can choose upstart or sysvinit for Linux, but then we need to deal with their current incompatibility with the Hurd and kFreeBSD ports of Debian. * It might be workable to have most services use init.d files even in the future, and then use sysvinit on the non-Linux ports. However, this removes much of the benefit of the new inits on Linux. * We could require every package that provides a service that needs to be started by init to support both sysvinit and upstart or systemd. However, given the realities of Debian development, this would probably mean that one of them would be badly tested, and therefore likely to be buggy. * We could try to have a tool to automatically convert an upstart or systemd service configuration into a sysvinit init.d script. I have no idea if that is really feasible, but if it worked for most packages, we could probably live with the others requiring some manual work. * We can decide to drop those ports. They're not used a lot, but they do have a loyal and enthusiastic fan base, even if small. Dropping them is not an easy decision. Keeping them is also not easy, if it means compromising the quality of the Linux version of Debian. This is probably what causes most of the emotional distress. * We can attempt to port upstart or sysvinit to the Hurd and kFreeBSD, either by changing the userland code or the kernel code. This may or may not be a large undertaking; I don't know if anyone's actually attempted it yet. (As a side note, if Canonical wants to stick with upstart, it'd be in their interest to have Debian use it too, I think, and perhaps they could do the Hurd and kFreeBSD porting?) Did I miss anything of substance? I don't know what should happen next, except someone should take leadership on this issue and find a rough consensus on what we as a project want to do. The usual way of that to happen is for someone to grab a keyboard and start writing actual code, as opposed to e-mails. Do-ocracy ftw. [1] http://lists.debian.org/debian-devel/2012/02/msg01043.html
signature.asc
Description: Digital signature
