[pacman-dev] New pacman testing RC

[Roman Kyrylych]

2007/1/23, Dan McGee <dpmcgee at gmail.com>:
> On 1/23/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > On 1/22/07, James Rosten <seinfeld90 at 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 (Роман Кирилич)