Commit 48a21cbf authored by Duncan Coutts's avatar Duncan Coutts
Browse files

Fix an InstallPlan.failed assertion

Remove the wrong assertion:
  all (`Set.notMember` failedSet)  (tail newlyFailedIds)

This is wrong for much the same reasons as the part of the invariant
(in the previous patch) was wrong.

Suppose Q depends on P1 and P2 and the processing set intially is
{P1, P2}. Now suppose that P1 fails, so the failure set becomes {P1,Q}
and the new processing set is {P2}. Now suppose P2 also fails. Then the
newlyFailedIds is [P2, Q] and so the tail is [Q]. Of couse Q is in the
failure set already, in violation of the above assertion. But this is a
perfectly reasonable scenario. It's just the assertion that is wrong.
parent 21be7d9d
...@@ -571,7 +571,9 @@ failed plan (Processing processingSet completedSet failedSet) pkgid = ...@@ -571,7 +571,9 @@ failed plan (Processing processingSet completedSet failedSet) pkgid =
assert (pkgid `Set.member` processingSet) $ assert (pkgid `Set.member` processingSet) $
assert (all (`Set.notMember` processingSet) (tail newlyFailedIds)) $ assert (all (`Set.notMember` processingSet) (tail newlyFailedIds)) $
assert (all (`Set.notMember` completedSet) (tail newlyFailedIds)) $ assert (all (`Set.notMember` completedSet) (tail newlyFailedIds)) $
assert (all (`Set.notMember` failedSet) (tail newlyFailedIds)) $ -- but note that some newlyFailed may already be in the failed set
-- since one package can depend on two packages that both fail and
-- so would be in the rev-dep closure for both.
assert (processingInvariant plan processing') $ assert (processingInvariant plan processing') $
( map asConfiguredPackage (tail newlyFailed) ( map asConfiguredPackage (tail newlyFailed)
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment