[Aptitude-devel] Bug#1019447: Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation

Axel Beckert abe at debian.org
Fri Sep 9 23:42:07 BST 2022

Control: severity -1 wishlist
Control: tag -1 + confirmed

Hi Aleksey,

Aleksey Midenkov wrote:
> > Aleksey Midenkov wrote:
> > > Since some version aptitude started to behave strangely: it asks user
> > > interaction after each successful installation.
> >
> > I thought that the "Press Return to continue" was always there, just
> > the "'q' followed by Return to quit" has been added as a feature
> > somewhen 7 or 8 years ago. But now I'm no more sure if that "Press
> > Return to continue" was really there before.
> No, it was not always there. I've been using aptitude for 20 years or
> so.

Me too, after I discovered that its so much better than dselect. (And
yes, I initially also was just a user. :-)

(And JFTR: As of now I'm mostly the packager of aptitude, not its
"upstream" developer, mostly due to lacking C++ experience.)

> When it started to be nagging it really freaked me out, but had no
> time nor will to fix until now.

I can relate. UI changes can be very annoying for some people while
other won't even barely notice that something has changed. E.g. UI
changes is what drove me away from GNOME many years ago. But which
change actually annoys someone seems to be a very subjective thing.

> > > So no obvious reason to use 'q' from the above interaction because 'q'
> > > also works from the UI.
> >
> > No, the reason is that you don't have to wait to reload the database
> > before being able to press "q" again.
> But it returns to UI first and hence reloads the database, so you have
> to wait in any case. Haven't you?

I remember that I once mentioned that I used to press just Ctrl-C
there. And someone of the aptitude developers back then said that's a
bad habit because aptitude then can't save back some details.

So as far as I understand there is some database saving part happening
during that time where it goes back to the TUI to properly quit. And
it is said to be needed to avoid the loss of some package states in
aptitude's pkgstate database.

> > > I guess the above pause was added to display
> > > the errors if any happened
> >
> > There is no pause in that sense. The time the UI is displayed is AFAIK
> > needed to properly write down the current state of aptitude's package
> > list after the package installation.
> Pause means do nothing and wait for user interaction. The delay caused
> by UI reload is not the "pause", is it?

Ok, I might have misunderstood which pause you meant. I initially
thought that you referred to the waiting time while consolidating and
writing the database back on disk as "pause".

But now I think you refer to aptitude sitting there and waiting for
the user to press (at least) Enter as "pause". There it is indeed a

> > > I hope you will find the below patch well-suited for stopping
> > > bugging you with that useless pause.
> > >
> > > --- b/src/ui.cc 2020-05-21 06:32:38.000000000 +0300
> > > +++ b/src/ui.cc 2022-09-09 13:41:49.752101187 +0300
> > > @@ -1276,7 +1276,7 @@
> > >      pkgPackageManager::OrderResult rval = f(-1);
> > >
> > >      bool quit_after_dpkg_run = false;
> > > -    if(rval != pkgPackageManager::Incomplete)
> > > +    if(rval != pkgPackageManager::Completed)
> > >        {
> > >   cout << _("Press Return to continue, 'q' followed by Return to
> > > quit.") << endl;
> >
> > Doesn't make sense to me. But maybe I also still haven't understood
> > what you're actually trying to achieve.
> Why it doesn't make sense?

For me it doesn't make sense to show the prompt if something (whatever
it is) is not completed. It is though unclear to me what is the exact
semantic of Incomplete and Complete in this case.

> When error happens it pauses and shows the reply.

I see. And indeed, I actually prefer to always be able to have a look
at the console output before returning to the TUI.

So this is obviously something which should be configurable as there
are different personal preferences on this.

I hence propose an option which allows the user to choose between
these variants:

* Always pause/prompt before retuning to the UI. (Current

* Only pause/prompt before retuning to the UI if there was an error.

* Never pause/prompt before retuning to the UI.

Additionally it might be an idea to also add either a separate
setting, additional keybinding besides "gg" (e.g. "gG") or a fourth

* Exit instead of returning to the UI.

> > What exactly do you expect aptitude to do when the package
> > installation/update/removal run ended?
> Return to UI without any interaction.

I see. Thanks for this explicit hint. It really helped to see that you
really want that. (Previously I couldn't really imagine this as I'm
quite happy that it stops there. I'm just annoyed that can't say
"quit" when starting the run, hence the fourth item above. :-)

> Again, that is stupid:

I disagree. :-)

> when you run some lengthy installation you go away from display and
> when you return back it asks for Enter then it forces you to wait
> until UI is reloaded.

JFTR: We're talking about a second on a 5 year old PC with SSDs and at
most a minute or two on a very old legacy system with slow
CPU (e.g. a Pentium 4 Mobile) and a slow, rotating disk.

I see your point, but if its worse or better than the initial variant
which you want back depends a lot on how you use aptitude.

Let me summarize:

* Initially there seemed no "Press Enter" at all. There you then had
  to press "q<Enter>" and aptitude would save its stuff, but you don't
  have to wait unless you need the shell prompt directly again.

* In between you had to press Enter, then wait until you can press "q" to
  quit and then wait again in case you need the shell prompt directly
  again. This was clearly the worst combination. 

* Now you have the option to press "q<Enter>" before it is returning
  to the TUI for saving some stuff to disk, but you also only have to
  wait for that if need the shell prompt directly again.

  From my point of view this is slightly better than the initial
  variant as the pressing of "q<Enter>" comes earlier (before the TUI
  is loaded again and not afterwards) and hence saves you these
  seconds (or minutes) you argue about by only having to wait for them
  in case you want back to the shell prompt.

  I though see that if you start such a run and get back only later, you
  loose a few seconds. Seems to depend a lot on the way how someone's
  using the TUI.

> That interaction didn't help me in any single case.

At least some people (obviously the person implemented or requested
this and me myself :-) want to see that output in any case.

I see quite a few cases where it makes sense to wait before the user
is acknowledging that the output has been seen (or is not relevant):

E.g. it is very useful if you have APT plugins like how-can-i-help
which output some information at the end of each run. Also with local
post-action hooks which e.g. run hardlink over /usr/share/doc/ and
then display some statistics about the save disk space benefit from
that prompt.

Anyway, let's see this as a feature request. It might count as UI
regression, too, but I don't see it really as a bug. Hence I set the
severity to wishlist, but also tagged the issue as confirmed, i.e.
that there is indeed need for such a feature.

I'm though aware that adding a configurable option is way less trivial
than hardcoding a different behaviour. Nevertheless: Patches for such
a feature are of course welcome. :-)

		Regards, Axel
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

More information about the Aptitude-devel mailing list