]] Kel Modderman > > ]] Roger Leigh > > > > > I'm not sure myself. Probably because it's potentially dangerous > > > since it would want to replace it with a symlink, and that might > > > result in dataloss. Do you have an example of the virtual > > > facility problem? > > > > Why would it want to replace it with a symlink? AIUI, insserv just > > renames the files in /etc/rcN.d ? > > No insserv doesn't just rename files it removes/recreates symlinks as needed > depending on change to the computed dependecy graph when adding/removing a > node.
Why will it ever remove a file? > The current behaviour is to ignore regular files which are installed to the > symlink farm, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493202#85 That doesn't look like a particularly good reason to ignore regular files vs symlinks? > Having random regular files in amongst a symlink farm which is dynamically > created dependning on service set installed is a recipe for mess and I cannot > think of a clean way to handle the situation other than conveying a message > that says "Don't do that please use update-rc.d to register your service and > create start/stop links with optimised priority depending on your current > service set" - but thats getting a bit wordy for a one line message ... There's no reason for the message to be a single line. > > For the latter, I seem to have: > > > > : tfheen@qurzaw /etc/init.d > grep Provides bootlog* > > bootlogd:# Provides: bootlogd > > bootlogs:# Provides: bootlogs > > bootlogs.sh:# Provides: bootlogs > > > > which makes it complain about something already provided. > > One of those scripts (bootlogs/ bootlogs.sh) must be an orphan conffile ? That shouldn't matter to insserv, but yes, one of them is an orphan. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
