>> When update-rc.d calls insserv, the rcN.d directories are rebuilt >> without taking into consideration any adjustment that might have >> been set up locally. That seems to be done on the assumption that >> the dependencies coded in the LSB blocks are universally accurate. >> Now, LSBs are a great improvement over numeric priorities, but to >> hamper local system tuning, which is not necessarily related to >> LSBs, IMHO is an insult to the legendary versatility of SysV init. > > I believe it is not how things work now. Last time I checked, call > `insserv foo` does not update any links to `foo' if there is already at > least one of them. > > @Jesse, am I right?
I just ran a quick test and can confirm that if I have an existing link to a service, for example /etc/rc5.d/S05bluetooth, then running the command "insserv bluetooth" will attempt to remove the old symlink and replace it with one that conforms to the LSB headers. In my case, removing the original link and creating /etc/rc5.d/S04bluetooth. Now, as to whether this should be considered a bug or a desired effect is open to debate. On the one hand it is understandable people might not want insserv to overwrite their changes. On the other hand, in my case insserv is fixing a mistake in my symlinks, and adjusting them to match their LSB headers. My thought on this is if someone wants to improve their start-up routine it makes more sense for them to edit their script's LSB header and re-run insserv rather than editing links by hand.
