Your message dated Tue, 29 Dec 2015 13:43:15 +0000
with message-id <[email protected]>
and subject line Re: [Aptitude-devel] Bug#793307: Bug#793307: aptitude: Add a
confirmation for changing 'automatic' flag
has caused the Debian Bug report #793307,
regarding aptitude: Add a confirmation for changing 'automatic' flag
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
793307: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793307
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.6.11-1+b1
Severity: wishlist
Dear Maintainer,
I occasionally pressed 'm' button when 'All installed packages' item was
choosen, so all my packages were marked as manually installed. 'm' is placed
right under 'j' which is often used for navigation, so occasional
presses on it is a real problem for me. Please, add some kind of
confirmation for changing package 'automatic' flag with 'm' button.
Also, I saw some bugs when aptitude forgets 'automatic' flag for some
packages and I thought some of them may be inspited by occasional 'm' press.
-- Package-specific info:
Terminal: rxvt-unicode
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.6.11 compiled at Nov 8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
apt version 4.12.0
NCurses version 5.9
libsigc++ version: 2.4.0
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 5.9.20150516
cwidget version: 0.5.17
Apt version: 4.12.0
aptitude linkage:
linux-vdso.so.1 (0x00007ffefdbc2000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
(0x00007f8c8d223000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x00007f8c8cfed000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007f8c8cdc3000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x00007f8c8cbbd000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x00007f8c8c8a7000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x00007f8c8c5d9000)
libboost_iostreams.so.1.55.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x00007f8c8c3c1000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007f8c8bfaa000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f8c8bd8d000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f8c8ba81000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8c8b780000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f8c8b56a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c8b1c1000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f8c8afbe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8c8adba000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8c8ab9f000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x00007f8c8a98f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f8c8a76c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8c8a564000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f8c8a35f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8c8dbe5000)
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing'), (99, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages aptitude depends on:
ii aptitude-common 0.6.11-1
ii libapt-pkg4.12 1.0.9.10
ii libboost-iostreams1.55.0 1.55.0+dfsg-4
ii libc6 2.19-19
ii libcwidget3 0.5.17-2
ii libgcc1 1:5.1.1-14
ii libncursesw5 5.9+20150516-2
ii libsigc++-2.0-0c2a 2.4.1-1
ii libsqlite3-0 3.8.10.2-1
ii libstdc++6 5.1.1-14
ii libtinfo5 5.9+20150516-2
ii libxapian22 1.2.21-1
Versions of packages aptitude recommends:
ii aptitude-doc-en [aptitude-doc] 0.6.11-1
ii libparse-debianchangelog-perl 1.2.0-5
ii sensible-utils 0.0.9
Versions of packages aptitude suggests:
ii apt-xapian-index 0.47
pn debtags <none>
ii tasksel 3.32
-- no debconf information
--- End Message ---
--- Begin Message ---
2015-09-12 21:17 To Артём Банщиков:
Control: tags -1 + wontfix
2015-07-29 21:36 Артём Банщиков:
On Fri, 24 Jul 2015 19:54:09 +0100 "Manuel A. Fernandez Montecelo" <
[email protected]> wrote:
2015-07-22 20:01 artem_banschikov:
On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert <[email protected]> wrote:
Hi,
If we do so, we should
a) make it optional (on by default is fine for me),
Completely agree.
b) only ask for confirmation if it would catch more than one package
(i.e. for whole branches)
I thought about three options: ask for one package, ask for multiple
packages, not ask at all. There is file deletion dialog in Ranger
file-manager made in this way.
c) only for "m", not for "M" (as the subject may suggest)
Confirmation for "M" may be added for consistency.
Anyway I'll be glad if you make exactly as you said as it will entirely
solve
my problem.
Best regards, Artyom.
What about Undo (Control-U), as Axel suggested in the previous e-mail?
IMO it is a more general solution, and already implemented, so it should
be
favoured rather than adding these new options (unless it does not work).
1) It may be not obvious for unexperienced user.
2) It may be not noticed quickly enough.
But optional warning in status screen may be added for using "m" on
multiple packages.
I am still not convinced that this is a good idea to add, so I will mark
it as +wontfix for the time being.
Justification:
In principle it should be harmless to add another confirmation dialog
for those cases where users might not notice the action, but in practice
it needs a lot of work: to add additional config options, handle them in
code, add code and signals to show dialogs and react to confirmention
events, document all that, translate the documentation, fix bugs for the
implementation mistakes several years down the line...
And surely, if one has confirmation for that relatively harmless action,
there are others which are much more dangerous and also deserve
confirmations: removing/purging, or reinstalling (can break running
services in the machine).
So I don't want to start the argument of the slippery slope and blame
global warming on confirmation dialogs; but suddenly this is not just a
harmless new dialog -- implementing this leaves less time to work on
other pressing issues, and all of that added complexity makes aptitude
more difficult to maintain in the long term.
Even if we had infinite time to implement all that (e.g. it would not
detract to work on other things, etc.), I think that increasing the
number of dialogs and config options for aptitude is actively harmful
and makes the program less useful, so it should only be used with a good
justification.
As to the questions that it may be not obvious for the unexperienced
user or not noticed quickly enough... in my opinion, setting a package
as manually installed is generally harmless, compared to most things
that can be done on aptitude, and not a real problem in 99% of cases
other than added cruft.
Closing, for the reasons stated above.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
