[Aptitude-devel] Bug#141663: aptitude: new group "New Packages in Woody" like "New Packages" for people using pins

[Manuel A. Fernandez Montecelo]

Hi,

2016-06-09 12:59 Jö Fahlke:
>Hi!
>
>Thanks for looking at this.  But you misunderstood what I had been asking.
>
>"~N ~Aunstable" will not select the packages that are "new in unstable".  It
>will select the packages that are "new" *and* that are "in unstable" -- which
>is something quite different if you have experimental in you sources.list.
>
>Likewise, and much more relevant: "~N ~Atesting" will select "new" *and* that
>are "in testing", which is something completely different from "new in
>testing" if you have unstable in your sources.list.  If you do weekly reviews,
>then "~N ~Atesting" will select almost no packages.  Any package that is in
>testing now but wasn't in testing last week almost certainly was in unstable
>last week and thus won't be matched by "~N".

Of course, it all depends on one's use-case.  Under such scheme, for
example, one would only unmark packages as New when:

a) one is interested in some packages in New, and waits until they had
   transitioned to testing; or

b) if, of all the New ones in unstable /today/ one is not interested at
   all, one can unmark them right away -- no need for them to migrate to
   testing


For normal users, the rate of installation of new packages is probably
less than 1 per week, otherwise the system would explode very soon
(counting new dependencies installed).

So I was assuming that either the reviews would be very frequent
(daily~weekly) and would be of case B most of the time, or far away in
time (> 1 month) and of case A (so most New packages would have migrated
to testing by then and could be installed directly).


>I am aware that this requires a database that remembers the state of all
>packages the last time aptitude was told to forget (key "f" pressed).
>Something like that must already exist for "~N" to work -- but I'm quite sure
>for "?new-in(...)" to work you would need to keep track of more information
>than is beeing done currently.

Yes, at the moment is just a binary flag New.  For tracking what's new
in the different suites one would need something similar but per suite,
with some complications like what happens when one changes the suite in
sources (more complex to handle than the current binary flag), the cases
of autoremoval from testing, etc.

My issue is more with the complications of how to represent this in the
current curses interface (which is far from trivial, given the current
trees/groups implementation), if we present that in command line mode in
some way, all the documentation (or changes) needed, etc.; and
because...

>That beeing said -- I am ok with closing this even though no alternative
>exists.  These days I probably would not do weekly reviews to learn of
>exciting new packages anyway, so it isn't as relevant as it was.  And no-one
>else has expressed a wish for that feature.

... yes, I see it as a very specialised feature, needing significant
work for relatively little gain; when one could achieve similar results
adapting the patterns as in the example above, or using other methods
[1] [2].

Another feature request related to New, which would be simpler to
implement and potentially as useful for this case, is forgetting new
packages individually [3] (or with patterns).

In that scenario, adapted to your case, one could forget regularly all
the ones which are not interesting (section by section, or even
"forget-new !~n^fantastic$"), and monitor every now and then the still
marked New to see when they transition to testing, and install.

Hopefully this sounds interesting.

Thanks for your understanding and your suggestion, in any case.


[1] E.g. the project news, every month or so, list the interesting /
    relevant new packages already "filtered".

[2] (I recently learnt that some devels learn about new packages by
    reading a mailing list of all incoming packages... very surprising
    for me).

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421043


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