[Aptitude-devel] Bug#498059: Always offer a "q" choice to [Y/n/?] etc.

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: close -1


2008-09-06 18:44 jidanni at jidanni.org:
>Package: aptitude
>Version: 0.4.11.9-1
>Severity: wishlist
>
>Please harmonize these prompts (and any others),
>  Accept this solution? [Y/n/q/?]
>  Do you want to continue? [Y/n/?]
>by adding a "q" choice to the latter. Yes, totally the same as "n" here.

Having "q" and "n" doing the same will not be good either.

If implemented, we would soon have bug reports from "somebody" asking to
clarify the difference between the two, or complaining that it's absurd
to have the two when they actually do the same, etc.


>The reason is if one does e.g.,
># for i do echo $i; aptitude purge $i; done
>one will soon discover the frustration in sometimes not having the "q"
>available to get out of this one and on to the next one, without
>having to think further.

(Yes, I realise that there might be good explanations for the case
below, but since the generic example is used as a reason....).

Or instead of the command above; do:

   aptitude purge ${list}

and have to reply only once.

A much quicker solution is to not add to the list packages that one does
not actually want to purge, etc.  Or running aptitude with "-s" if one
doesn't know if the consequences of removing a bunch of packages are OK.


In any case, guiding the development of aptitude by users might want to
do when in frustration, is not a very sound design decision.


2008-09-08 17:06 jidanni at jidanni.org:
>And then there is the prompt,
>   Resolve these dependencies by hand? [N/+/-/_/:/?] ?
>
>Indeed here we type RET to get out of danger (removing, etc.) where as
>RET will get us into danger in the [Y/n/q] case.

The Y case is basically asking to confirm that you want to head with an
action that you requested.  If we default to "q" in those cases, we
would soon have requests for people complaining that "aptitude doesn't
default to the sensible request".

So, +wontfix and closing.

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