It already checks that it works to read the dump back afterwards. The problem is when several dumps are decoded due to cyclic dependencies and the whole resolver system turns over on its back. One can implement a check for that by loading each dump in a pike process that have essentially nothing else loaded aldready.
The problem is to decide from that which dump is the "faulty" one. Since the problem doesn't really lie in any single dump, that amounts toanalyzing the load dependencies in all the failed cycles and deduce a minimal set of dump(s) to remove. You could see it as a nice optimization problem if you like.
Also, I'm not positively sure that compiling a certain module from source will resolve the problematic situation in all cases, so the system should also tentatively remove those dumps and rerun the test to verify that the problem has gone away.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-03-23 00:53: Subject: 7.6
I mean if it is possible for it to realize the dump is bogus and abort it.
/ Martin Nilsson (provokatör)