[Aptitude-devel] Bug#707320: Bug#707320: marked as done (aptitude: implement partially forgetting new packages)

Fri Aug 5 16:52:24 UTC 2016

Hey...

On Sun, 2016-07-24 at 15:41 +0100, Manuel A. Fernandez Montecelo wrote:
> Given that it's an improvement over the previous functionality (all
> or
> nothing), in any case, it's more flexible than before...  but I
> disagree
> that it's more unflexible than your proposal (read on).

Hmm I tried it now for a few days, and while in principle it allows for
more things to do, my original view hasn't changed and I'd still
consider unfortunate for practical use. :-(

The major use case I'd have seen in the selective forgetting is that
one can keep those packages one wants to have a look at later on.
This use case typically means that only a small subset of the new
packages is wanted to be kept (otherwise one could just keep all).

This in turn however makes the matching based solution rather
impractical for day to day use:
- new packages turn up in many sections, and often not all of those in
  one section are interesting enough to be kept
  thus filtering out based on the section doesn't really seem to work
  in many cases, and even if it would one would still have to type in
  all those sections one wants to discard (which can be quite some)
- filtering out single packages is unhandy either
  As I've said before, it's typically the minority one wants to select
  but the filtering works vice-versa (i.e. selecting all those one
  wants to discard). Even without fast growing sections like dbg[sym]
  this end up being unusable.
  Inverting the filter wouldn't help IMO either, one would still need
  to write up all those packages that are to be kept, and since one
  needs to navigate through the package view and often all interesting
  packages wouldn't fit on one screen, I'd alrady need another editor
  or so, where I write up the interesting things.

> Had the "F" shortcut not been taken for a completely different
> purpose,
Doesn't F anyway make just sense on already installed packages?
While there can be packages in the New section which are installed (but
just not forgotten yet),... I'm sure no one would bother if F would get
another meaning when one is in the New tree.

> I would have let "f" behave as before or perhaps implement your
> suggestions (context-based, forgetting depending on where you
> are).  But
> I didn't want to add a completely different shortcut, or have the new
> feature only accessible through a menu, that perhaps people would not
> discover for a long while.
hmm..

> One of the problems that I found with your suggestions is that if
> people
> don't know about the feature and press "f" expecting that everything
> is
> forgotten as before, and only one package or a small section is
> forgotten, they might think that forgetting-new is not working at
> all,
> or not working properly, or at least it will be puzzling for a while
> until they learn that it's a "new feature" and how to use it.
Well but that's a general problem with evolution of software... you add
new features, and when people don't read the changelogs, they won't
know about it.
With that argument one could more or less never change anything.

I'd have expected that some NEWS.Debian entry about any new behaviour
would fix any such conernts..

> In the new implementation, the pop-up might be surprising the first
> time, but it's pretty obvious what it needs to happen: just press
> "enter" for the old behaviour, or use package names for patterns, as
> suggested in the dialog.  I think that it introduces nicely the new
> feature to the users, while only being minimally disruptive for the
> ones
> used to the old behaviour.
But it still "breaks" user "experience".
I for example end up basically every 2nd time, pressing f then g
(because usually I do the upgrades afterwards), but now the "g" goes
into the popup.

> Added bonus is that at least it needs an extra key stroke to have the
> old behaviour clear all new ("f + Enter"), so it's likely to trigger
> by
> mistake than before (which happens from time to time, and a case for
> which your suggestions in that bug report don't improve when people
> press the key by mistake).

Maybe one could have also "completely" changed f's behaviour, i.e. not
immediately forget the package (and refresh the view), but just mark it
dark grey or so (i.e. scheduled to be forgotton)... and when people
exit aptitude, and/or perhaps on "g", and/or on some "save forgotten
status function"... it would have been actually saved.

This would make the "need" for an extra key stroke go away and allow
people to undo their "f" without Ctrl-C aptitude.

btw: I don't think that f+Enter really solves the issue you try to
address above.
As soon as people will get used to the popup, the f+Enter will go into
flesh and blood for most, and the extra key stroke won't work as a
guard anymore.

> Also, it's easier to clear away all packages in ways that do not
> conform
> to the current visible hiearchy, e.g.:
> 
> - forgetting-new all packages from a source package
> 
> - or a pattern based on source package names (e.g. ~n*texlive*)
Both nice to have,.. but again, I don't think of much use in practise:
For the source packages: There are often cases where I'd find one
binary package of a source package interesting... but not all the -dbg,
-common, lib*, -doc etc. simply because when I look at the main
package, this would anyway recommend/depend/suggest everything else.

And the regexp thingy... well this always means that one has to come up
with such regexp first.

On Sun, 2016-07-24 at 15:54 +0100, Manuel A. Fernandez Montecelo wrote:
> I forgot a couple of points...
> 
> Or alternatively, if the screen is updated in every time that a
> package
> is forgotten, then the view would be reloaded and the whole tree
> would
> be collapsed (as it happens in other situations where the package
> states
> change).

That could perhaps be solved with the "just mark it grey" idea I had
above?

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20160805/737b894d/attachment-0001.bin>