Comment 14 for bug 1296711

Created attachment 96661
reset the flag to show the problem

I was able to reproduce the bug as described by Victor with the packages "aptitude" and its dependency "aptitude-common", and will use them as an example in the discussion below.

* We start with both packages installed.
* By requesting the removal of "aptitude", Package::setRemove() (in libqapt) will try to resolve any dependency problem arising. To do this it also calls pkgProblemResolver::Protect() (in libapt-pkg).
This causes "aptitude" to be marked as "Protected" in the depCache.
* When unmarking "aptitude" muon uses Package::setKeep() to unmark the package.
* When we try to remove "aptitude-common" Package::setRemove() uses pkgProblemResolver again to resolve dependences. But apparently the resolver will not touch "aptitude" because the "Protected" flag is still in place.

I attach a patch *against libqapt* to prove the concept, but it is a hacky workaround. It changes what should be an internal flag of apt-pkg. On the other hand I see no other way to change it.
Does the resolver really need that flag in the cache?

A different point is, why does the error message give no reason?
The dialog box is shown because the depCache correctly reports 1 broken package, i.e. "aptitude". But Package::brokenReason() is called on "aptitude-common", which has no reason to be broken.
Is this a bug too? not sure.