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

[Manuel A. Fernandez Montecelo]

2016-08-05 17:52 GMT+01:00 Christoph Anton Mitterer :
> 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.

I didn't implement this new functionality with section names in mind,
etc for this particular use case.  I just reused patterns, which is
how many other aptitude functionalities work.

I don't know why you focus the discussion in sections only.  One might
discard by any pattern, including "forget all new but those from
section games", "forget all without that debtag", "forget all not from
this source package", "forget all which are not part of kde", "forget
all which don't contain this word in it's description: GPG", "forget
all which are not called php* or gnome*".

This is vastly more powerful and quick than forgetting packages one by
one, when there are many.  If there are 140 new packages every time
that one upgrades/looks into the list, forgetting it one by one it
would be vastly more tedious in comparison to filter out those 140
packages by using 1 to 10 patterns.

Also, one can use user-tags for this.  In your case it might not work,
but again it's a vast improvement over the previous case when it was
only all-or-none.


You have a tendency to generalise problems as if all people used
aptitude in the same way as you and experienced the same frustrations.
But frankly, many of the things that you describe look quite strange
to me and I never heard of anybody needing to keep more than a
screenful of packages marked as new because they are very interesting,
in every update.  Most of the "new packages" coming every day are
actually -dbgsym or renames of libraries, so they're not even "new" in
a sense.

So, well, I am sorry if it doesn't work well for you, but it's a vast
improvement over the previous situation for many use cases, it's not
worse than before for the rest, I am happy with it and I am not going
to undo it even if you don't find it useful.  Even if yours was
implemented, this one would stay.

And your suggestion had the problems that I described, mostly a
headache in terms of implementation, so I'm not contemplating it at
the moment.


>> 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.

Yes, packages can be Installed and New, I have plenty of them in my system.

"overloading" the meaning of F would be a bad idea IMO, if nothing
else because it would confusing in the documentation, but also because
the implementation doesn't permit to do this cleanly.


>> 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 

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

[Manuel A. Fernandez Montecelo]

I forgot a couple of points...

2016-07-24 15:41 Manuel A. Fernandez Montecelo:


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.


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).

So it would be very cumbersome / not really useful if one wanted to
unmark package as new one by one (which is presumably the use-case for
forgetting-new packages individually or by non-top-level subtrees), or
it would need a lot of modifications in aptitude and perhaps the widget
library to update packages and view while keeping the cursor in the same
place and the subtrees open ("in the same state"), effort which at this
point I am not able to commit.



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).


... it's _less_ likely to trigger by mistake ...


Cheers.
--
Manuel A. Fernandez Montecelo 

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

[Manuel A. Fernandez Montecelo]

Hi,

2016-07-24 14:51 Christoph Anton Mitterer:

Hey Manuel.

I've seen the new functionality for marking new packages forgotten, but
to be honest, it seems rather a bit unflexible in use (especially when
one wants to mark only a certain set of packages as forgotten).


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).



Have you seen the ideas I've had proposed in #707320? Where the "f"
button would basically be similar to the current semantics (i.e. not
opening a pop-up), but depending on the current selected item, either
forgot single packages, or subtrees, or everything.

I could imagine e.g. the following:
- if a single package under "New" is selected (and f pressed), forgot
  the single package
- if a tree like "Admin section" is selected, forget everything there
- if the whole "New" tree is selected, forget all new packages
- if the cursor is completely outside the New tree (but e.g. under
  updates or so), let f jump to the new tree, or give a popup warning,
  or e.g. give the same pop-up you have now, that allows to ender
  expressions.


Yes, but there are several problems that I tried to address and which
with these suggestions do not cover, specially given the way that it
worked previously (for a decade or more).

Had the "F" shortcut not been taken for a completely different purpose,
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.


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.

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.

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).

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*)

- or everything not in section games or kde -- which maybe is the only
 set of packages that you're really interested in keeping as "new" to
 install later


So yes, I considered your suggestions before implementing this, but for
the reasons above I think that this way is actually much more flexible
-- it's not limited to the current visible hierarchy, but exploits the
full power of search patterns, which is about the epitome of flexibility
that aptitude brings to package management.


Cheers.
--
Manuel A. Fernandez Montecelo