On Thu, Oct 20, 2011 at 3:55 AM, Dave Reisner <[email protected]> wrote: > On Wed, Oct 19, 2011 at 09:37:22PM +0200, Markus Jochim wrote: >> Dear developers, >> >> I'd like to request a feature. When I search for some package, let's >> say openconnect: >> >> $ pacman -Ss openconnect (or -Qs) >> >> it takes quite a while until I get any results on my netbook (Atom >> N450 cpu). Maybe this could be sped up by showing exact matches >> right away. I've had this situation quite some times now and it can >> be a real pain in the ass to wait for 10 seconds (this may vary of >> course) when I simply want to know whether I have a particular >> package installed. >> >> Kindly, >> >> Markus >> > > Hi, > > The overhead here is disk I/O, not CPU. Looking for exact matches first > will not save you any time. Additionally, once your local DB is paged > into RAM, results should come much more quickly. > > To humor you, and assuming your DBPath is /var/lib/pacman, you can use > something like the following bash function to get exact matches: > > # assumes extglob is enabled > findexact() { > res=(/var/lib/pacman/local/$1-+([!-])-+([0-9]))
I noticed a slight problem here- PKGBUILD(5) states the pkgrel variable is "not allowed to contain hyphens". So I realize possibly this, as well as my fix for bacman, is not exactly correct. I haven't checked the pacman code though, can you confirm? Actually all of my local packages conform to the common practice of making pkgrel an integer, but I know a package in AUR, namely fortune-mod-tbbt, currently at 0.2-3.1, and presumably pacman doesn't complain about it. > [[ -d $res ]] > } > > The function returns 0 (found) or 1 (not found). > > I make no guarantees that this continues to work in the future as it's > dependent on our DB format. > > dave > >
