I'd be interested in knowing whether setting Aptitude::ProblemResolver::Trace-File to something (e.g., /tmp/aptitude-trace.tar.gz) and then triggering the bug produces a useful cut of the cache.
I didn't know about this... The package lists seem OK, but I'm not sure about the trace. It's in the attachment.
Also, I did a little debugging, and found out this may in fact be a bug inaptitude.You mean apt?
Yes, sorry.
BTW is it necessary to call internal_mark_install() after set_candidate_version() in aptitudeDepCache::apply_solution() in this branch?I believe that set_candidate_version doesn't actually call MarkInstall(). It looks like each of the 3 calls to set_candidate_version is followed by a call to mark_install, so probably merging the two would be feasible. OTOH, this would require rewriting the undoer for candidate versions to undo the install too, and given that the current code, although ugly (like a lot of the very old code in aptitude), seems to be correct and isn't exporting its ugliness excessively, I'd rather not mess with it and break invariants I've forgotten about.
That's OK, but I thought more if MarkInstall wasn't superfluous when we're upgrading an already installed package, but I may be wrong so don't treat that too seriously.
Regards
Jiri Palecek
trace.tar.gz
Description: GNU Zip compressed data

