[pacman-dev] New pacman testing RC

Dan McGee dpmcgee at gmail.com
Tue Jan 23 11:15:37 EST 2007

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)
community/guisvn 1.0-1 (depends on subversion)

Just my thoughts. The only other thing would just be to dump this
behavior all together, but it does seem helpful in those cases such as
cdrecord where a rename occurs (btw, searching for cdrecord doesn't
yield a whole lot of helpful things- someone needs to look at these


More information about the pacman-dev mailing list