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

[Aleksey Midenkov]

Axel,

On Sat, Sep 10, 2022 at 1:42 AM Axel Beckert <abe at debian.org> wrote:
>
> 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. :-)

Right.

>
> (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.

Agree. I believe the subjectiveness comes from the amount and variety
of UI experience.

>
> > > > 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
> pause.
>
> > > > 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.

If you don't understand the semantics then it doesn't make sense for
sure... But in that case this fact doesn't make sense itself.:)

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

Why? I had to have that habit before. But now I don't pass useless
info through myself.

>
> 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
>   implementation.)
>
> * 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
> option:
>
> * Exit instead of returning to the UI.

All that is kind of an obvious solution. But investing into such a
development over the originally wrong design seems to be an unpleasant
thing. The couple of points should be considered first:

1. Why would somebody need to see the output of successful completion?
How can that help?
2. Are there different better designs to solve anybody's needs?

Besides, why wouldn't you try my patch and reconsider how you feel
about it. Maybe there is some objectiveness behind my
subjectiveness... ;)

EOF (I'm not cutting anything below and above).

>
> > > 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



-- 
@midenok