Control: tags -1 + pending
Hi Torsten, 2009-03-12 19:23 Torsten Scheck:
Package: aptitude-doc-en Version: 0.4.11.11-1 Severity: normal ch02s03s05.html: --------------------8<-----------------------8<------------------- ?true, ~T This term matches any package. For instance, ``?installed?provides (?true)'' matches installed packages which are provided by any package. --------------------8<-----------------------8<------------------- The given example search pattern matches packages _which provide any package_. You could also adapt the search pattern to the given description results: ?installed?reverse-provides(?true) This would result in a list of installed regular (non-virtual) packages, which are provided by other packages. Please adapt either the search pattern or the description.
Applied the first solution, thanks.
--------------------8<-----------------------8<------------------- ?virtual, ~v Matches any package which is purely virtual: that is, its name is provided by a package or mentioned in a dependency, but no package of that name exists. For instance, ``?virtual!?provides(?true)'' matches packages which are virtual and are not provided by any package: ie, packages which are depended upon but do not exist. --------------------8<-----------------------8<------------------- Here is another active/passive confusion. The given search pattern matches virtual packages which _don't provide any package_. This yields all virtual packages on my system, so maybe the description is correct and the search pattern has to be adapted: ?virtual!?reverse-provides(?true) On my system this yields no matches, though. Is there a purpose for this or for the original search? A more interesting search might be ?virtual?reverse-provides(?installed) which matches virtual packages which are provided by any installed package. The more examples, the better...
Again, you are right and the original doc is wrong. In fact, ?virtual does not match packages mentioned in a dependency but not available, not recently (checking with chocolate-doom and the dependency chocolate-hexen, with non-free disabled), and also checked with the ancient version 0.6.3-3.2+squeeze1 from 2011 (upstream release mid 2010), cytadela-data and unavailable dependency fareditor. The pattern matching happened or was heavily modified in only in 2008 and has not been much changed since, so I think that this never actually worked as documented. Also, these packages do not show in "virtual packages" subtree of the main package view. So all seems to point in the direction that the documentation is actually wrong. "aptitude search '?reverse-recommends(?true)' | grep 'chocolate-'" also does not return anything, while the same grepping for aptitude does show entries. On the other hand, "aptitude sarch '!?reverse-provides(?true)' | grep '^v'" does not return any match, meaning that indeed it cannot yield any matches in your system, the intersection of ?virtual and that is the empty set. So since this has been working like this for many years and in different parts (not corner cases, but crucial ones like the main package view), I just fixed the description and substituted it for your example, which I like and it's less confusing.
--------------------8<-----------------------8<------------------- ?depType(pattern), ~D[depType:]pattern [...] If depType is ``provides'', matches packages that provide a package matching pattern (the equivalent of ?provides). Otherwise, matches packages which declare a dependency of type depType upon a package version which matches pattern. --------------------8<-----------------------8<------------------- The parenthesis "(the equivalent of ?provides)" is useless and confusing after the change from short to long forms. Before, this remark pointed to ~P in the description of ~D.
I think that it is a bit reduntant but useful, at least in the HTML version, because it contains a link to '?provides' and it makes explicit that they should behave the same (otherwise people might wonder why there are two ways to achieve what apparently is the same, and wonder if there is some fine detail that they are missing). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
