Hi, I just ran into the same issue on Squeeze when moving to insserv and concurrent boot. While it wasn't a problem to create some overrides for bootchart and bootlogd, the basic question that comes up here repeatedly seems to be:
> The insserv maintainers (aka me and Kel) are aware of the $all issue, > but as stated earlier a bit unsure how to best solve it. I see two ways to solve this: 1) Realize that indirect dependencies on $all (like in this case through rmnologin) are logically broken and forbid them outright. Make insserv fail as long as such an essentially cyclic dependency is present, so it gets fixed soon, if necessary by NMU. If failure is no option (breaking people's boot process is frowned upon), at least warn loudly. The current modus operandi of silent failure is badly broken. 2) Play it nice and find a "do what I mean" solution. I'd personally prefer (2) and would implement it as such: Make $all a virtual facility that depends on every other facility, except those that directly or indirectly depend on $all. This follows the basic principle that "most specific matches win" and thus a specific dependency on rmnologin is stronger than a general dependency on $all (or for that matter, any meta-dependency). Now the actual problem seems to be how to do the above with the current codebase. The data model seems a bit low level to do graph relayouts or set operations comfortably... The high level algorithm to achieve the above ordering seems clear: 1. Add all facilities to set A 2. Make $all a virtual facility that depends on set A 3. Scan A for any facility that depends on $all and move them to set NA 4. Scan A for a facility that depends on any facility in NA 5. If you found one, move it to NA and go to 4 6. Establish the correct ordering in sets A and NA 7. Done - emit A followed by NA Of course this would be optimized around steps 4 and 5 to avoid double tests, but it comes up with the ordering we actually expect: In the given case, bootchart et al would move to NA where they would be ordered after rmnologin, as expected. I clearly don't grok the source, but a first guess on how that might be achieved without too fundamental changes would be to modify all_script() so that, in the process of cranking out a new order higher than any existing order for all the SERV_ALL facilities, would also reset the SERV_ALL bit. After that, rerun the ordering process once again to reestablish dependencies on facilities moved during the previous step. I just don't see how to do this easily :-/ Is this problem known upstream? TIA, An "Down to 15s boot thanks to insserv, startpar - and an Intel SSD" dre. -- Cool .signatures are so 90s... -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org