[Aptitude-devel] Bug#563297: [aptitude] warn when changes affect large subtrees

[Manuel A. Fernandez Montecelo]

Control: retitle -1 aptitude: warn when changes affect large subtrees
Control: tags -1 + wontfix
Control: close -1


Hi,

2010-01-01 19:53 C Sights:
>Package: aptitude
>Version: 0.6.1.3-3
>Severity: normal
>
>Hi,
>	If 'm' or 'M' is pushed while a category (e.g. "Installed Packages") is
>highlighted, all packages in that category are either marked as manually
>installed ('m') or automatically installed ('M').
>	This could be a nice feature, but at the same time it can destroy a lot of
>information about how and why a package is on the system.  E.g. the first time
>I fat fingered 'm' I saw that all the packages were marked as manually
>installed, but didn't know that I had caused it.  Then I exited aptitude
>normally and the changes were saved.  Now I have craploads of libraries marked
>as manually installed.  Yuck.
>	Perhaps an intervening confirmation or a message saying "you have pushed 'm'
>while selecting a category, thereby marking multiple packages as manually
>installed, to revert to previous markings, push 'z'".

I've been considering this request, and I think that it would be mostly
clutter and an annoying feature than an actual help.  (Warning every
time would enrage many users relying on this behaviour, and providing
alternatives has other tradeoffs, see below).


The reason why I think that this extra "feature" would not be of much
help is because the consequences of mass-marking packages are reversable
and, in any case, marking itself is not very destructive from what I can
see, for several reasons:

- For one, there's the generic "Undo" operation, which would have helped
  in this case to revert the bad keypress, and it's been present for
  quite a few years.

- Marking itself is not a very dangerous operation, because any
  operation like "Upgrade", "Install", "Purge", etc., or marking the
  package as automatically installed (and thus triggering a possible
  deletion) need confirmation before proceeding, so people can reverse
  the actions before the real-deal (which is a requirement in aptitude).

- If the action that triggered this was to mark all installed packages
  of section "libs" as manually installed, rather than automatically
  installed, the solution is simple: press "M" again, as originally
  intended.  Doing "m" and "M" again would not have any difference
  compated to only marking "M" in the first place.

  This is not a contrived or ad-hoc example -- most operations on a set
  packages show the same property, only the last action is preserved.
  It doesn't matter much if one presses other keys before, only the last
  one prevails (m/M are independent from install/upgrade/etc, but
  reverse each other's actions).  If one wants to mark all as
  "[m]anually installed" and presses "auto[M]atically" installed by
  mistake, then "m" again, it results in the same as if pressing "m"
  without the mistake.  If one wants to upgrade and presses "purge" and
  then "upgrade", it is the same as pressing "upgrade".

  In the case that there are some quirks of the implementation
  (e.g. with recommends/suggests), it can be fixed as per point #2.



Regarding warning every time as being annoying, if we don't want to warn
every time, and instead just have a configurable option to disable it,
we would have to spend still more time implementing, further cluttering
the available options, documenting and translating it, and maintaining
it over the years.

This is true for every feature, of course, but when I try to weight the
pros and cons (including value/effort ratio) comparing it to many other
things that need to be done to fix wrong behaviours of aptitude or
improve it in other ways, I think that this would be towards the very
bottom.


Since this is just days short of 6 years old, and I don't see it being
addressed any time soon even if somebody does think that it would be
positive to implement it, so I am marking as +wontfix and closing for
the reasons stated above.


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