[Frans Pop] > I have to say that I disagree with that. I have tried insserv on my > laptop last month and was not all that happy with the way it worked. > > My objections are summarized in: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465587#35
I am aware of this, but believe you do not have to worry as much as you do. As far as I can see all of your problems originated from the lvm2 script missing headers, and my bad decision to drop override files for packages with headers in unstable, while forgetting to make sure those headers were also making it to testing before the new version of insserv. When scripts have correct headers, the boot sequence stays correct, and if there are scripts with incorrect headers, installing them will either be rejected (because of loops), or that packages script will get an incorrect location in the boot and shutdown sequence (obviously, as the dependency information is used to order the scripts. In your case, the lvm2 script got the default headers (depend on $remote_fs and $syslog), which is wrong for lvm2. It got it because insserv was upgraded and dropped the correct override file for lvm2. It will not happen again (because I will not remove override files before scripts are fixed in testing), and did not break the boot sequence as it refused to mess with the working sequence as soon as the resulting loop was detected. Since your report, I have checked the packages you noticed with large jumps in the shutdown sequence, and reported those with bugs in their header, or missing header, to BTS. Your feedback was very valuable, and I hope for more test reports to weed out the remaining bugs in the dependency information provided by init.d scripts. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
