[Aptitude-devel] Bug#570492: aptitude: TUI reselects just removed packages for installation

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo unreproducible


Hi Sven,

2010-02-19 09:20 Sven Joachim:
>Package: aptitude
>Version: 0.6.1.5-2
>Severity: normal
>
>Start aptitude as a normal user and select a package (preferably a leaf
>package) for removal or purge.  Press 'g' twice and become root, press
>'g' twice again to actually remove the package.
>
>Now aptitude will display "Will use nnnnkB of disk space", and if you
>press 'g' again you'll notice that the just removed package is marked
>for installation.

I cannot reproduce this with 0.7.5, the version currently in unstable.
Can you still reproduce it nowadays?

There have been changes related to this in the last few versions which
maybe fixed this behaviour, for example:


0.7.5

  * Save state before package reconfiguration (to not be lost) (Closes: #474876)

0.7.3

  * Update internal state for upgrades/downgrades with target version after the
    action is performed (Closes: #787658, #714429)

    Thanks to David Kalnischkies and Julian Andres Klode from APT team for their
    help, clues and patience.  It took some serious effort to get to this fix,
    which in the end is quite modest in terms of code changes.

    Internal state was neither reset nor written to disk until other packages'
    states changed, so aptitude marked the same action on the packages as
    pending to be performed again and again (but the action had already been
    taken, so there was no observable effect in terms of installations).

    However, this meant that the packages that were downgraded to older versions
    when newer were still available (e.g., mixing stable and unstable), was not
    shown as "Upgradable" neither in the current sessions nor in subsequent
    sessions (under Upgradable subtree in interactive mode; or command line like
    "aptitude search ~U"), until the file pkgstates was written to disk because
    of changes in other packages.


Maybe other previous changes in the 0.6.* series, after the version in
which you reported it, fixed this as well.

Unless you can reproduce it, I guess that some other change fixed this
problem without this bug being closed.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>