In my example above, your code gave me LA -> XYZ -> BLAH which only satisfies rule 1 above. To satisfy rule 2, FOO and 3 other items must also be removed. In other words, it only appears to go down (DFS) not back up. I am honestly not trying to be dense here. The code I am using is below:

Oh, I think I see what you mean now..

Here is something that I think does what you want:

Read more... (1367 Bytes)
You do a DFS from the target, following edges backwards. The resulting list will tell you all of the items that depend on the target. These are all the items that we know must be removed if the target is to be removed (according to your rules). The fact that we used DFS here doesn't really matter, we just need a list of all vertices that can reach the target.

Now we have a list of items that must be removed. Before removing any item, we must first remove all of its dependents. This where the topological sort happens. Doing a DFS (following edges forward) from some item X results in a topological sorting of the items that must be removed if you want to remove X. So we can just do a DFS from each of vertices in that list. We re-use the %seen array so that these multiple DFS calls don't repeat (similar to how you would do topological sort on an entire graph, by starting new DFSes until everything has been seen).

On a side note, it seems slightly odd that you would remove all of FOO and all of its dependencies as a result of removing BLAH. What if BAR or XYZ are required elsewhere? Are there more conditions than are captured in this small example?

blokhead

blokhead,
After an hour an a half, I convinced my co-worker he was full of contradictory statements and what he said he needed wasn't at all the correct definition of the problem. After figuring out what he really wanted to do, it turned out to be a simple matter of constructing a "depends on me" tree and then using the topological sort.
Read more... (2 kB)

Cheers - L~R

blokhead,
On a side note, it seems slightly odd that you would remove all of FOO and all of its dependencies as a result of removing BLAH.

Yes, it does seem odd. There is a 3rd unwritten rule that says

• You can't uninstall an item that has a non-existent dependency
In other words, if I get rid of BLAH without getting rid of FOO, I can never get rid of FOO. Also, there is no reason not to get rid of FOO because it will no longer work. I will confer with my co-worker to determine if there is an exception to this rule (a "must keep" list that says it is ok to leave a package in an inconsistent state). Alternatively, I will ask him if there is a technical restriction on removing a package before its dependencies since that would allow me to get rid of FOO but leave the other packages it depends on.

Cheers - L~R