Comment 10 for bug 1062503

I guess I found the problem. Or in fact two problems, just that the first hides the second and the second isn't an error condition. In short: SmartConfigure for an M-A:same package will do a lock-step configuration for all other ((to be) installed) archs. It just doesn't check if the package it wants to configure was unpacked causing us to configure not unpacked packages here.

The second is in SmartUnPack which does a similar looping over the M-A:same architectures of a package, but this time of course for unpack and that is the second "problem": It will happily unpack packages we have already unpacked and configured as it isn't checking for that case either -- as this can't happen anyway as you can see here. ;)

Your testcases have no problem with that change, but I have to admit that I was unable to create a testcase for this bug so far (mvo's works, it's just to big…). As this bug-ordering-solution has a rather unusual way through dependency-hell it would be quiet good to have one though. :/

(Attached is the same patch as in my lp branch for your cherry-picking convenience -- patch-name-pun intended)