Gunnar Wolf

First of all, sorry for the delay. Leaving just as the discussion gets started is bad, yes... But I'm only now reading Erich's and Sven's follow-ups. Both (as well as some comments in my blog) ask why not integrating the startup links in each of the packages - Well, basically because I don't think that most maintainers will take care to do this, and we will end up having a situation very close to what we have today: If I'm not interested in supporting your favorite init system in my packages, I just won't bother to make the scripts.
Note: I'm going into braindump mode. Verbose blabber and some stupidity might follow ;-)
Think on the webapp scene - Most webapps ship with an Apache-like snippet so that http://yourserver/thisapp just works(tm). I love that, and it's one of the little details that make Debian shine - Things usually work with the least administrator burden possible. But it happens that there are other web servers around there - They just become somehow second class citizens (I happen to sponsor/comaintain Cherokee, for instance), as nobody cares to include the equivalent snippets for them. Apache is the standard, and is good enough.
The same goes for sysv-rc: It just rules the world. Who will work all the needed patches to support all the different init systems? As the maintainer for a simple package which requires to be started up, I probably won't care to even understand all the intimacies of every init system, at least until they all have a decent user base. But by having one package per (server,init-scheme) pair, any maintainer can come up with the needed initialization.
Of course, this degrades quickly. First of all, as a user: if mydaemon is not correctly starting up, I will probably file bugs at mydaemon, not at mydaemon-initscheme. If mydaemon changes its parameters, we will witness transition of mydaemon-*.
Further, remember this is Debian, and volunteer-work has its downsides. If the mydaemon maintainer is a primadonna (or just does not give a flying crap about the runit init scheme), he will just trash reports regarding a nonimportant init scheme. Bad. And, as Erich points out, we have ~1000 packages including /etc/init.d/something - It will mean 3000 or so packages for a decent (not complete!) coverage of the different schemes. And, of course, a very uncoordinated way of working. But back to my line of thought: If I'm promoting an init scheme, I cannot just push it down each maintainer's throat. I must include at least the most important init scripts somewhere. Maybe we could just group daemons by task, and then have -say- a webservers-runit package providing the init scripts for each webserver for runit? This could cut down from 3000 to some 100 packages, most probably team-maintained... But it still faces many scalability problems, and the bug-filled-somewhere-else problem seems unavoidable.
I think something interesting could come off Sven's idea of providing several independent scripts instead of today's complete init scripts - This would make it easier to adapt startup/shutdown and similar events to different world views, and if not specifically needed, most init scripts could even be autogenerated calling the right bits here and there. That would rock - except in the corner cases (I predict no less than 10% of the packages will become corner cases ;-) ) where it will crumble apart. But maybe if a package declares it should be autostarted and provides the separate bits, the sysv-rc, upstart or runit helper can come up with an autobuilt initscript (or equivalent) - And if it does not work, it can always be overriden by a maintainer- (or user-) supplied, explicitly built script. Humh...
The topic surely calls for a Debcamp session, as Joachim says in comments in two of our posts and Erich acknowledges. Erich, as the main instigator of this blog series, I hope you can at least join via Ekiga or such, as it can be quite interesting - But, yes, none of the people involved so far participates in any of the inits' maintenance... Anyway, please keep the ideas flowing. I want to sketch something up, as I feel this can be useful - and not only for initscripts, but for many of the areas where Debian provides several ways to do the same thing. And, once again, that's one of the best points of Debian for me.