[Aptitude-devel] Bug#320095: aptitude: counts for reverse-recommends and reverse-suggests could be handy

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


Hi,

2005-07-26 23:38 Brian Kimball:
>Package: aptitude
>Version: 0.2.15.9-3
>Severity: wishlist
>
>Hi again.  I'm finally purging my aptitude thoughts.  One more to go
>after this. :-)
>
>I find %r to be very useful in providing at-a-glance information as to
>whether I need a package installed or not, especially when I don't know
>much and don't particularly want to know much about a package.
>
>%r doesn't quite provide the whole picture though: it doesn't tell me
>at-a-glance if any other packages recommend or suggest a package, so
>when I'm cleaning out unwanted packages I often find myself constantly
>checking their reverse-dependency listings before hitting the purge
>button.  This process can get pretty tedious, especially when confronted
>with the long reverse-dependency listings that I addressed in my other
>wishlist.
>
>If we had similar escapes for reverse-recommends and reverse-suggests we
>would all be able to see immediately just how many other packages find
>a particular package useful.  No longer would we need to enter a new
>screen for each and every package.  Just scrolling through the package
>listing would be enough.

Similar as for #320092, there doesn't seem to be much reason with recent
versions of aptitude to continuously monitor rev-dep lists for the
purpose of removing packages, nowadays the "auto-installed" packages
functionality should serve this purpose.


>You already have a lot of escapes already, so maybe %r could change to
>displaying 5 characters: d/r/s.  Those wishing to only see actual
>reverse depends can limit the width to 1 character.
>
>What do you think?

I think that in general this is a very thorny area.

For example, one would expect that this count behaves correctly with
"automatically install recommends" or "automatically install suggests"
and "recommended-important" and "suggests-important" and several other
variations of the options, and that if unmarking some of these options
later, that the new situation is taking all that into account.  That's a
quite big amount of combinations, and it's probably difficult to match
the expectations of all people in this regard.

Worse is the situation with provided (virtual) packages.  Should the
rev-depends of all provided packages be counted?  What if a rev-dep
depends on multiple provided packages of a single package, should it be
counted only once or every time?  If we decide to count only one in the
previous case, what if v1 of rev-dep (fantastic_1.0) depends on provided
package 1 (e.g. libfantastic-abi-1), and v2 of the same rev-dep depends
on another provided package of the current package
(e.g. libfantastic-abi-2) -- should we count it twice in this case?

Furthermore, how do we count alternatives, and what if virtual packages
are involved?  Because if the package in question is www-browser or
mail-user-agent and several packages providing it are installed, or the
rev-dep depends on (pkga|pkgb) and both are installed, one can uninstall
the package being reviewed anyway.

So all of these questions (and probably many more) have to be considered
when implementing this, it's not a simple question of traversing a graph
and counting, that's probably why the doc mentions explicitly: "Outputs
the approximate number of installed packages which depend upon the
package."


2005-07-28 16:57 Daniel Burrows:
>On Tuesday 26 July 2005 03:38 pm, Brian Kimball wrote:
>> You already have a lot of escapes already, so maybe %r could change to
>> displaying 5 characters: d/r/s.  Those wishing to only see actual
>> reverse depends can limit the width to 1 character.
>>
>> What do you think?
>
>  If I did this, I'd probably resolve the problem by extending the syntax of
>format codes, similarly to how I extended matchers.  For instance,
>
>  %(r:Recommends)
>
>  I tend to think, though, that the pattern and format languages are getting a
>little too complicated, and rather than adding lots of variations on their
>codes for all sorts of obscure situations, I'd rather just add hooks into a
>real programming language such as Python...although, of course, it's a lot
>easier to hack up individual special-case fixes to each situation as it comes
>up. :P

Overall, and again as with #320092, 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.

Much less to implement hooks to other programming languages.

So marking it as +wontfix.

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