On Fri, 28 Dec 2007 04:10:14 +0100, Daniel Burrows <[EMAIL PROTECTED]> wrote:

  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 in
aptitude.

  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

Attachment: trace.tar.gz
Description: GNU Zip compressed data

Reply via email to