2007/1/23, Dan McGee <dpmcgee@gmail.com>:
On 1/23/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
After you left IRC, we realized klapmeutz was correct about the provides thing. We realized that kernel26beyond said it provides kernel26 in its info, while kernel26ck, kernel26mm, and kernel26suspend2 do not say they provide kernel26. More evidence pointing to this is that pacman -Ss ^mpd$ (with smoons repo which has mpd-svn) shows both mpd and mpd-svn.
Yeah, I didn't even notice it regexes 'provides' as well... in fact, that doesn't appear documented anywhere and I actually didn't know it worked that way.
Do we want this behavior? While I can see if being useful, shouldn't the actual output contain something to indicate WHY it matched?
Odd that it regexes provides and nothing else- matching depends would make just as much sense (say you were trying to find a GUI subversion client or something).
If we keep these other fields in our searches, I think we need to do something a bit special when they match. For normal name/description matches, we should keep the output the same. For a provides (and maybe depends) we could take at the end of the name line something like this (fictional package name, btw): community/guisvn 1.0-1 (provides subversion) OR community/guisvn 1.0-1 (depends on subversion)
I don't think adding depends is a good idea, because we'll get a lot of matches for some packages. If we want to have depends matching - then it should be "reverse depends" feature. ;-) Example: # pacman -Sr subversion community/guisvn 1.0-1 . . . # pacman -Ssr ^subversion$ community/guisvn 1.0-1 . . . -- Roman Kyrylych (Роман Кирилич)