On Fri, Sep 29, 2006 at 09:33:18AM +0200, Toni Mueller wrote: > Hello, Hi Toni,
> I suggest the following resolution of the problem: > > If there's an SV entry in /etc/inittab, the user probably already had > daemontools in use. Since the run scripts require (small?) > modifications to be compatible with runit, in this case having a second > /etc/inittab entry would be appropriate to facilitate soft migration. > Since the default run directory for daemontools is /service (the FHS > version after daemontools-installer uses /var/lib/svscan), there is no > collision with what the runit package installs at this point. So, just > pick a different service name and figure out which entry belongs to > runit by checking for runsvdir vs. svscan. > > Suggested service name: "SVR". > > The advantage for this method is that it allows both easy migration to > 'SV' once daemontools are dropped, and that it also doesn't require any > of the debconf stuff. Hmm, currently the installation of the runit-run package does the migration from /service/ to /var/service/ automatically, and I've found users being pleased with that. Does this conflict? > FWIW, people who use daemontools are supposed to know what they are > doing since integration with Debian is rather poor, imho. So, they will > figure out by themselves when and what to do with /etc/inittab, w/o > requiring massive tool chain support. Yes, but that's how it currently is. If daemontools is installed, the installation stops with an error, so that the user can fix it up, and disable daemontools before installing runit again. Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
