Comment 14 for bug 1134492

General:
Limiting a solution to Conflicts would be bad, that should work with Breaks too, as Conflicts should be avoided like the plague (if we can). And just doing it on Conflicts (or Breaks) does make it apply to a lot of cases there we don't want it to happen (think: libfoogtk2-0 conflicts/breaks with libfoogtk3-0) so we need some more heuristic here than just this (aspcud is just based on numbers, so it works here, but fails then the solution is not just a numbers game).

I can only really comment on that with an example though (a dpkg/status file and sources.list might be enough until a test surfaces. Setting up a system to test just this isn't exactly easy …). Frankly, I don't see why this is considered "high" though: switching X-stacks doesn't sound like an everyday task, so I guess everyone could live with a slightly longer commandline to type (aka: copy&paste) and a "low" or similar…

Quick-Review (just looking at diff, no applied or anything)
1. A user can easily have more architectures configured than just two, so comparing architectures is dangerous.
2. Not all of these architectures are a good choice (think: armel on armhf or armhf on a amd64 crossbuilder).
3. Please do a patch against trunk. We can always try to backport it later.
4. MarkInstall (and for that matter MarkDelete) can fail and you should do something sensible if they do, not just ignore it
5. Do we really want to do something even if the removed package is M-A:foreign ?

Serious nitpick: Don't name a variable iPkg if you use Pkg in the same context, while its definition is far away. It's very easy to miss (which I did initially and wondered why you renamed Pkg to iPkg and wanted to nitpick about unneeded renames first…)

Lesser nitpick: Instead of Z, use P as an iterator. If you are used to APT code you know immediately which iterators are G, P, V, D, … no such hint for Z (okay, at times P stands for Provides, but every rule has an exception – and usually its Prv instead).