Looking more closely (because it's especially bad for multiarch), I see that it appears to be caused by applying holds too late.
Let's say we have the following versions and dependencies: A=1 (installed) A=2 Breaks: B B (installed, held) C (installed) Depends: B (or any similar scenario, in my case A having available versions A:amd64-2 and A:i386-1, B:i386 depending on A:i386) If the resolver wants to upgrade A to version 2, it will decide that it needs to remove B and C. It only then processes holds, marking B and (transitively) A as kept. C still remains marked for removal, even though any reason to do so is gone. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
