> ]] 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?
It removes symlinks and creates new ones with an updated sequence number when the sequence number changes dues to adding/removing a new script, it doesn't remove regular files when present in symlink farm it ignores them. > > > 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? This reference was to give previous history on the sub-topic we're talking about (a regular file in symlink farm), not to give reason to another shit behaviour of insserv but xplain how the current behaviour came to be. > > > 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. True, thanks for the tip. I'm happy to extend the warning to something more verbose if given a clue what people would rather read in this case. > > > > 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. And it does matter - you may hate the design but that's the way it is - scripts cannot co-exist when they provide the same facility, unless they are grouped into virtual facilities. Look I love insserv as much as the next man, its not going to change much semantically between now and the time a modern init system can become the boot system for Debian because its not worth throwing excess time and effort down that sysvinit path. Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
