[Aptitude-devel] Bug#246672: aptitude: quit directly instead of pressing a key to continue

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending

2016-03-11 13:12 martin f krafft:
>also sprach Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com> [2016-03-11 00:22 +0100]:
>> So having that into account, what's the reply to the question
>> above?
>
>It seems a bit too much to have to return to ncurses and let
>aptitude not only rebuild its cache, but also build views etc.

So implemented now.

Despite the modest amount of changes in the end, there was lots of time
involved in solving this and other problems found in the way, causing
crashes or undesired effects when trying to do more direct things like
"exit()", "cwidget::toplevel::shutdown()" and others in sequence, etc.

Currently it seems to work fine, but there is a slight chance that it
needs to be pulled out if it still crashes under some conditions that
were not tested.

The commit comment follows.


    [curses] Be able to Quit after dpkg run (Closes: #246672)

    The current implementation seems to work, but the handling of these issues
    is a bit brittle and with lots of circular dependencies, with signals and
    events happening everywhere.  E.g view (cwidget objects) being reloaded
    automatically when cache is reloaded, while cwidget is supended for dpkg
    run.  The initial events trigger further updates and triggers using cwidget
    objects and other structures, sometimes depending on different options being
    enabled or how the curses mode was launched (e.g. "visual preview", or
    "solution screen").

    In any case, the cache needs to be reloaded (and with it, state saved to
    disk) to perform some updates/cleanup after dpkg runs, like resetting
    "reinstall" state when done (the "save pending reinstall" was implemented in
    this version), or unmarking upgraded packages as needing upgrade after the
    version has been upgraded to the desired one (bug fixed in this version,
    when aptitude was not acknowledging the "upgrade" as having taken place, and
    still marking it as update in the next runs).

    Presumably all of these complications are why this hand't been implemented
    before, in all the intervening years.

    Still I thought that it was worth to implement it now because it will now at
    least save the user/system from spending time in some of the curses actions,
    save a few extra keystrokes, and with it a few seconds (specially in slower
    systems) having to keep an eye just for quitting.


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