https://bugs.kde.org/show_bug.cgi?id=331730
Carlo Vanini <silh...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |silh...@gmail.com
--- Comment #12 from Carlo Vanini <silh...@gmail.com> ---
Created attachment 96661
--> https://bugs.kde.org/attachment.cgi?id=96661&action=edit
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.
--
You are receiving this mail because:
You are watching all bug changes.
