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

Sat Aug 6 02:03:44 UTC 2016

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

"With that argument one could more or less never change anything." --
true, but since this discussion is because of a new feature that I
added, I actually did changed something, so this remark looks a bit
odd.

And if I added a NEWS.Debian entry for every slightly relevant change
/ new command / new functionality that I added in the last year, it
would be quite a few screenfuls when one jumps from one Stable to the
next.

The point is, changing user expectations / backward compatibility in
significant ways without a major justification is not good, or even if
there is, like all the discontent with GNOME and other project prove.

I don't think that changing the behaviour in the way that you describe
would be a major beakage, but it is a small problem nevertheless,
which was what I was saying, so it weighs in the pros/cons.

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

If every second time that you update the list of avaiable packages you
have to type "<backspace><enter>" for a few days/weeks, it doesn't
look a very drastic problem, compared with the benefits (the benefit
of learning that one can use more powerful syntax now and having the
box right there).

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

Actually, nothing is saved until g or exit or similar actions happen
(it's not a new behaviour, it's been like that since forever).

However, the actions of the keys and their result is sometimes deeply
embedded and entangled with other actions, and in this case is a
reload of the whole tree.  So yes, could eventually be done, but it's
not that simple.

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

This already happens now, but Control-C is not recommended for
aptitude.  "Cancel pending actions".

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

It acts as a guard for bug reporting though -- in the sense that when
somebody submits bugs about it, I can point the finger and say "there
was your safe guard".

More seriously, I expect that if people do f+Enter as a matter of
"finger memory" is because they were used to "f" before and simply
don't care much about the New functionality.

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

I think that you're generalising again how you use aptitude and the
things that you find useful with the ways that other people use it.

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