[Thorsten Glaser] > Hmm. This does not answer the question, while it does point out one > package. I’d rather sysvinit not depend on insserv, it used to work > fine without that kind of added complexity, and AIUI, it was only > used for parallel boots
Note, I can with authority, as the person introducing dependency based boot and shutdown ordering in Debian, report that insserv were not introduced for parallell boot, nor for boot speed. It was introduced to correct broken boot and shutdown ordering using a system wide reordering of every scripts at once. This was needed as it proved impossible to get every package maintainer involved in a boot sequence reordering to lift together in a finite amount of time, where the last one in a sequence had to change its number, before the second to last changed its number, and so on and so forth. There were lots of incorrect sequence numbers in the boot and shutdown sequence before we introduced dependency based boot ordering, and this was solved when we introduced dependency based boot ordering. By all means, feel free to try to reintroduce the static sequence number ordering again, if you believe it is a sensible way forward. I recommend to use the dependency information provided in the packages to verify you get it right. The /usr/share/insserv/check-initd-order script can be used to compare the sequence numbers with the dependencies, to detect any errors. After we introduced dependency based ordering, the sequence number that used to be passed to update-rc.d was made obsolete, and it is not really used any more. This means the number, if it is provided, can no longer be trusted. The 'start/stop' arguments for update-rc.d is no longer supposed and have not been supported for several years. There is no going back to static sequence numbers without changing around 1000 packages to add these sequence numbers back. I wish you luck motivating the maintainers to reinsert them. Personally I was a very happy when I did not have to pick a number between 00 and 99, and instead could just state relationships with other init scripts. Just wanted to clear any misunderstanding about the use of insserv being related to speed and running scripts in parallell. It is not true. Insserv provided correct ordering, and a byproduct was that correct ordering made it possible to run scripts in parallell for higher speed using startpar. -- Happy hacking Petter Reinholdtsen
