> Yes, this is how it should be done. That way, people can use familiar
> /etc/init.d/package scripts to control the service instead of having to
> learn daemontools.
I don't agree with that. If people don't want to learn daemontools why they
are using it? They can use daemontools for dnscache and other
daemontools-needing software WITHOUT switching init.d-services to
daemontools. So I don't see a need in those init.d-scripts.
It may be ok if there are init.d-scripts only called by the user, but these
script are called also by the system on startup. I think this can be an
error-source. If someone knows daemontools but is not familiar with the crazy
way it is implemented into debian and such a init script is doing something
nasty (Like starting the service even if it's marked as "down") the user is
confused and wonder why debian is calling "svc -u" in some init scripts.
Sorry, I don't see the point why we should "wrap" daemontools with init
scripts. If you don't want to use daemontools, don't switch to it.
Implementing runlevel-support into daemontools can be done by modifying the
run-scripts and the svscan init script. There is no need to write
init.d-wrappers for all daemontools services.
I hope this discussion is not ending in a solution where we mark ALL
daemontools services as "down" (To prevent svscan to start them
automatically) and starting them ONLY by init scripts. If you do it in that
way, you have a clean solution to be compatible to the init.d mechanism but
you have thrown away the advantages of daemontools.