[Steve Langasek] > So it's not at all true that it's "not an option" in Debian - it > just happens to not be the option you prefer. I, OTOH, think it's > the better option;
Just for the record, I would prefer Debian to drop file-rc, and avoid the complexity of having two different systems manipulated by the update-rc.d API. It would make a lot of things easier, both with documentation and configuration. But until it is dropped, I believe it would be a mistake to pretend file-rc does not exist and do things in packages that only work with one of them. So it is not the option I prefer, it is the option forced upon us by the Debian project providing several different ways to handle the boot sequence and an incomplete API to manipulate it. :( > I'm not sure why anyone would want to run file-rc in the first > place, but I know exactly why someone would want to disable a > service by changing symlinks in /etc/rc*.d - because it's the > *right* way to do it in the context of sysv-rc. I believe those using file-rc use improved speed as the argument for selecting it. Did not try to benchmark it and compare it to the alternative, so I do not if this is true or not. And I must admit I expect those to change the state of services at the same rate as those using sysv-rc. > And insserv doesn't even enter the argument here, because insserv is > dependency-based and shouldn't need any configuration changes > anyway... Actually, disabling services when using insserv have the same problem. All changes need to go through the update-rc.d API, and there is no way to enable or disable single runlevels. The sequence number can be ignored in the insserv case, but not the state of the service in each runlevel. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
