(I'm marking this as important because I think it might point to a deeper
conceptual oversight in aptitude; downgrade if appropriate.)

This is using the debian package state as of today. I have squeeze, sid, and
experimental in my sources.list, in that order.

Consider:

$ aptitude search 'aspell-am ~Rrecommends:~i'
p   aspell-am                                                                       - Amharic dictionary for aspell
## So, aspell-am is recommended by an installed package.

$ aptitude search '~i ~Drecommends:aspell-am'
## What? No installed packages recommend aspell-am?
## OK, because aspell-am provides aspell-dictionary, which is recommended by an
## installed package.

$ aptitude search 'aspell-am ~Rrecommends:~i !~Dprovides:(~Rprovides:~i)'
## We can exclude packages that provide an already-satisfied virtual package.
---

$ aptitude search 'xz-lzma ~Rrecommends:~i'
p   xz-lzma                                                                         - XZ-format compression utilities - compatibility commands
$ aptitude search '~i ~Drecommends:xz-lzma'
$ aptitude search 'xz-lzma ~Rrecommends:~i !~Rprovides:(~Dprovides:~i)'
p   xz-lzma                                                                         - XZ-format compression utilities - compatibility commands
## Argh it didn't work!
## Because xz-lzma provides lzma, which is a *real* package.

$ aptitude search 'xz-lzma ~Rrecommends:~i !~Dprovides:~i'
## We can exclude packages that provide an already-installed real package.

----

In summary, these two commands are not duals:

$ aptitude search '~i ~Drecommends:X'
$ aptitude search 'X ~Rrecommends:~i'

but instead you need to do

$ aptitude search 'X ~Rrecommends:~i !~Dprovides:~i !~Dprovides:(~Rprovides:~i)'

This is very confusing, tedious for admins to figure out, and inconsistent.

It seems it'd be much simpler (at least for search) if aptitude treated virtual
packages in the same way as real packages, and the "provides" dependency as
other normal dependencies.


Ximin