[Aptitude-devel] Bug#320092: aptitude: provide more grouping and/or limits in reverse dependency listing

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


Hi,

2005-07-26 23:30 Brian Kimball:
>Package: aptitude
>Version: 0.2.15.9-3
>Severity: wishlist
>
>Hi, sometimes while investigating a package's reverse dependency
>listing it takes ages to scroll through the list (especially for some
>libraries).  It would be nice if by default it was grouped into first
>"installed packages" that defaulted to an expanded list and then "not
>installed packages" that remained closed but could obviously be expanded
>by the user.
>
>Limit functionality might come in handy also.  If limits worked in those
>screens then we could just quickly limit them to ~i when needed.
>
>Thanks!


2005-07-28 16:49 Daniel Burrows:
>On Tuesday 26 July 2005 03:30 pm, Brian Kimball wrote:
>> Limit functionality might come in handy also.  If limits worked in those
>> screens then we could just quickly limit them to ~i when needed.
>
>  Note that searches do (should) work in these screens, although it's of
>course not as convenient as a limit.

I agree that "limit" functionality working would be nice, but it doesn't
look very easy to implement.

I am not sure about providing more grouping/nesting in revdep list, I
think that it's already quite nested, and for most packages the list is
not that big.

Apart from that, some things have changed already since this report was
submitted, e.g. since recent versions the rev-deps are grouped in a
different subtree when they depend on a virtual package provided for the
current package.

Some of the reasons why rev-dep lists were inspected were to see whether
the package could be removed (e.g. #320095), functionality that it's
much better covered by the "auto-installed" packages.


Overall, the request was sitting for more than a decade with no
follow-up or intention to implement it, or even seconding, and I don't
consider that has a high priority either, so marking it as +wontfix.


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