[Aptitude-devel] Bug#438495: Cannot interrupt changelog download

[Manuel A. Fernandez Montecelo]

2015-09-22 1:55 GMT+01:00 Trent W. Buck <trentbuck at gmail.com>:
> If you want to WONTFIX or close this bug, I don't object. :-)
> Boring discussion follows.
>
> Manuel A. Fernandez Montecelo wrote:
>>> When viewing upgradable packages, one can use the `C' key (that is,
>>> Shift + C) to download and view the changelog.  While the changelog is
>>> downloading, both `q' and ^C (Control + C) terminate aptitude
>>> altogether; it seems there is no way to cancel the download of a
>>> changelog.
>>
>> Can you please confirm me if what you observed is still happening with
>> recent versions?  I's been quite a long time since the report and the
>> follow-up.
>
> I can reproduce the symptoms as originally described, on jessie & sid.
>
>     Open aptitude TUI,
>     select a package,
>     hit C,
>     then hit q (aptitude offers to quit) or hit ^C (aptitude quits).
>
> When I pressed q, the bottom line of the TUI reported:
>     Preparing to download the changelog of ganeti-haskell-2.15 ... 2%
> so I assume the download was in progress.
>
>> I am on a very slooooow connection, but even then the (and when
>> changelog is not on disk already) package changelog downloads so fast
>> that I cannot press 'q' before it downloads, except in a couple of
>> occasions.  Even with old packages (== assuming big changelog files) it
>> takes fractions of a second.
>
> IIRC it was noticable for me because changelogs were downloaded from debian.org, not a local mirror.
> In Australia that meant they took a loooong time.
>
> Right now on sid it takes about 1s for a package with a short changelog (haskell-zeromq4-haskell),
> and about 4s for a package with a long changelog (vim).

With vim also takes a while for me, also about 3-4 seconds.  I am
wondering if part of that time is not reading the chanlog and doing
some processing, like converting lists to be more visually appealing,
but in the end the problem is not different in this case.


>> Sometimes when pressing 'q', it seems to want to quit aptitude rather
>> than cancel the changelog (but there is the confirmation dialog).
>> However, assuming that in your case it's just very slow downloading the
>> changelog, I think that one can press F6 and cycle to another view and
>> continuing working there for a few seconds, as a workaround.
>>
>> To be honest, I am not sure if it's even a good idea to implement this
>> request, since I think the download happens in a background thread and
>> only creates the view (the one reacting to 'q') once the changelog is
>> ready.
>>
>> But maybe I am missing your use-case and why it's so annoying, please
>> explain.
>
> I do not really care about this bug anymore -- especially since, as
> you say, it is possible to continue working in the existing aptitude
> tab (view?) while the changelog downloads.

Yes, the new tab/view is not created until the changelog is ready to
be shown (be that download, parsing or rendering).

With vim I managed to click '+' on a package and getting the resolver
to mark it as broken in before the window of the changelog was shown,
so now it is possible to use aptitude normally.


> IIRC what used to happen was I'd hit <right arrow> by mistake,
> which sent ^[[C and aptitude would start downloading a changelog,
> and it was in the foreground but I couldn't cancel it,
> so effectively I was locked out of aptitude for a decasecond or two.

I can see how that was definitely annoying, yes :-)

With the window in the foreground I think that it would have been
easier to solve this by cancelling the action with 'q', that is, to
honour your request.

With the window not visible now, the solution would almost surely
involve menu actions (that might take longer to reach than the
download itself), or shortcuts (of which there are many already taken
and it's more and more difficult to find sensible keys for common
actions); and people are unlikely to even learn about this shortcut if
not in the menu.

These solutions are much more costly in terms of implementation
(specially in areas of documentation, screenshots and translations)
than creating the code for cancelling and connecting the signal of 'q'
with the cancelling action.


> That doesn't seem to be the case anymore :-)
>
> If you want to WONTFIX or close this bug, I don't object.

As I said in the a previous message and above in this message, with
the current less-annoying behaviour, the effort needed to implement
this (ost of the effort would not even immediate/by-me --e.g.
translations--, but still I think that it's worth considering), and
specially the long list of aptitude problems, I think that it's better
to spend time in other problems with higher impact or more common
complaints (this was not seconded since Josh in 2008).

I think that it is still a potential problem, or one that people might
want to report, e.g. because the new window interrupts you when
opening, so better to leave it as +wontfix, at least for now.  Maybe
there's the opportunity to implement it in the future as part of
"cancelling all network actions" or similar; or somebody wants to
implement this.

Thanks both for reporting and replying after such a long time!

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