[Aptitude-devel] Bug#822272: aptitude: No more forgets reinstallation instruction after reinstallation has happened

[Manuel A. Fernandez Montecelo]

2016-04-25 12:22 Axel Beckert:
>Hi Manuel,
>
>Manuel A. Fernandez Montecelo wrote:
>> >If I select a package for reinstallation by pressing "L" in the TUI and
>> >then press 2x "g", the package will be reinstalled.
>> >
>> >Afterwards at "Press Return to continue, 'q' followed by Return to
>> >quit."  I press <Enter> (not Ctrl-C) and it still lists that package for
>> >reinstallation.
>>
>> Hmmm, I cannot reproduce it
>
>Meh. Ok, I'll dig up some more details which could be related:
>
>* The packages in question are aptitude, aptitude-common,
>  aptitude-dbgsym and aptitude-doc-en 0.8-1. I wanted to reinstall
>  them because I had initially installed a self-built copy of it.
>  Haven't tested other packages yet, but will.
> [...]
>Hrm, maybe it's related to respectively only happens due to the new
>"aptitude can't uninstall aptitude" feature?

If you put the locally built packages in some dir that it's added to
apt's sources-list, I think that this is a problem that happens
independently of being "aptitude" packages -- packages with same file
names but different hashes, and libapt/aptitude somehow prefering one
over the other.

(I have the gut feeling that solving these cases cleanly, reinstall or
not, is an unsolvable problem in general).

If you have them outside source.list's dirs and install them with
e.g. dpkg or "apt local install", then I don't know.


>> and also the reason why "q+Enter" needs to do some processing rather
>> than exiting more quickly -- to detect upgrades and reinstalls and
>> other changes in states, and save it to not repeat them in later
>> sessions.
>
>I wonder why this needs to be done _after_ pressing Enter. Is this
>because it needs to go back into fullscreen curses mode to do that?

Basically, yes.  It's an entangled mess of a cascade of signals being
emitted about packages' states having changed and then saving the
information with the successful actions removed from pending, and
repainting the views and what not.  Signals and state updates are
entangled with code / classes paiting the "windows" and "views" and so
on.

The functionality could be duplicated for quit-before-reinstating-curses
and update-in-curses, but then code would be duplicated and probably get
out of sync quickly, etc.

In an ideal world the handling of those cases would be surgically
removed from the classes paiting the curses interface and separating
state updates and screen replainting, but this is not trivial or quick
with the current code.

After hours fighting with it I decided to settle with the imperfect
solution.  I hesitated a lot about going ahead and implementing the
request, because I knew that there would be complications like the ones
caused and then people would miss the feature if removed later...

But what people were doing (Control-C to save some seconds) was also
causing problems of their own, and resulting problems causing bug
requests difficult to trace later to the original problem and causing a
lot of extra work to triage bugs etc.

So... Rock and Hard Place and all that :)


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