[Aptitude-devel] Bug#808905: forbid-version vs. "Do you want to continue? [Y/n/?]"

[Manuel A. Fernandez Montecelo]

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


Hi,

2015-12-24 09:37 積丹尼 Dan Jacobson:
>Package: aptitude
>Version: 0.7.5-3
>Severity: minor
>
>Come to think of it, it is not entirely clear, when we get to
>"Do you want to continue? [Y/n/?]"
>if that means we are being asked if we are sure we want to forbid, or if
>that has already been done.
>
># aptitude forbid-version perl perl-base perl-doc  xserver-xorg-core
>Marking version 5.22.1-2 of package perl as forbidden
>Marking version 5.22.1-2 of package perl-base as forbidden
>Marking version 5.22.1-2 of package perl-doc as forbidden
>Marking version 2:1.18.0-1 of package xserver-xorg-core as forbidden
>Marking version 5.22.1-2 of package perl as forbidden
>Marking version 5.22.1-2 of package perl-base as forbidden
>Marking version 5.22.1-2 of package perl-doc as forbidden
>Marking version 2:1.18.0-1 of package xserver-xorg-core as forbidden
>The following packages will NOT be UPGRADED:
>  kmod{a} (R: module-init-tools)  libapt-pkg-perl{a}  libcommon-sense-perl{a}  libcurses-perl{a}
>  libfile-fnmatch-perl{a}  libhtml-parser-perl{a} (S: libdata-dump-perl)  libjson-xs-perl  libkmod2{a}
>  liblocale-gettext-perl  libnet-dns-perl  libnet-ssleay-perl{a}  libnetaddr-ip-perl  libsocket6-perl{a}
>  libterm-readkey-perl{a}  libtext-charwidth-perl  libtext-iconv-perl  libunicode-map8-perl
>  libunicode-string-perl  libuuid-perl{a}  libversion-perl{a}  libxml-libxml-perl  libyaml-syck-perl{a}
>  perl  perl-base  perl-doc  xserver-xorg-core
>No packages will be installed, upgraded, or removed.
>0 packages upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
>Need to get 0 B of archives. After unpacking 0 B will be used.
>Do you want to continue? [Y/n/?]
>
>Current status: 0 (+0) broken, 26 (+0) upgradable, 12630 (+0) new.
>
>Seen with
># apt-config dump|grep Aptitude
>Aptitude "";
>Aptitude::CmdLine "";
>Aptitude::CmdLine::Always-Prompt "true";
>...
>Aptitude::CmdLine::Verbose "1";

The last two options are relevant ^^


2016-01-08 23:53 積丹尼 Dan Jacobson:
>retitle 808905 Say instead "Will mark version XXX of package YYY as forbidden"
>found 808905 0.7.5-3
>thanks
>
>Today with 0.7.5-3 I am happy to report that if one says "n"
>aptitude indeed does not mark the versions as forbidden.
>
>However this is still after the words
># aptitude forbid-version less
>Marking version 481-1 of package less as forbidden
>
>Therefore please change the wording to
>Will mark version 481-1 of package less as forbidden
>
>(Before finally asking Do you want to continue? [Y/n/?])

This is a consequence of the combination of the two non-default options
above.  Until the last few releases, aptitude remained silent when doing
these operations even when verbose>0.  It was made explicit by some
request (probably yours).

  .oO( That proves, yet again, that even the most seemingly innocuous
       changes often bring a never-ending stream of maintenance work
       down the line ).


With the current implementation, the functions printing this information
(and similar for "keep"/"hold"/"auto-installed") don't know if the
prompt will later be forced to be invoked, so it's not straightforward
to achieve the requested behaviour.  Even if it was, it means adding
many more messages for all the different possibilities, adding work to
the tens of translations.

I don't think that it's a good to change/complicate even more the
current implementation for such a corner case.  If this was to be fixed,
maybe it would be better to just remove the confirmation messages and
assume that everything went fine.

In addition, as with the rest of aptitude behaviour, I think that it's
quite clear that if there's an explicit confirmation request, the
previous actions have not been taken.

More in general, if in any program one sees something along the lines
of: "Removing $blah.  Continue?  (y/n)", if one says no, the action does
not take place.  This is somehow occluded by the fact that other
messages about upgrading/removing/etc get in the way, but this is due to
another issue which hopefully it will be sorted at some point -- if the
never-ending stream of reported minor issues permit...

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764299


Summary: For all of the above, marking as +wontfix and closing.


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