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
