[pacman-dev] Feature request: Show exact matches first
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
On Wed, Oct 19, 2011 at 9:37 PM, Markus Jochim <ich@markusjochim.de> 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
Run pacman -Ss ^openconnect$ to get exact results - if any.
On Wed, Oct 19, 2011 at 2:37 PM, Markus Jochim <ich@markusjochim.de> 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.
What is the *problem* you have here? Printing exact results first won't make it faster, so this is not a solution to the problem you originally stated- " it takes quite a while until I get any results on my netbook". -Ss should not be slow these days; the second and later runs take no more than 0.8 seconds on my Celeron M 900 Mhz machine; the first run likely takes no more than 2 seconds. -Qs could still be slow, but without some actual numbers, I don't even know what ballpark we're in here. `time pacman -Qs wontfindme` output would be nice here. Either use a closed ^regex$ as Karol stated if you want exact matches, or give us some timings of the runs of each command so we can see whats up and fix your problem as stated. -Dan
On 20/10/11 05:45, Dan McGee wrote:
On Wed, Oct 19, 2011 at 2:37 PM, Markus Jochim<ich@markusjochim.de> 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.
What is the *problem* you have here? Printing exact results first won't make it faster, so this is not a solution to the problem you originally stated- " it takes quite a while until I get any results on my netbook".
-Ss should not be slow these days; the second and later runs take no more than 0.8 seconds on my Celeron M 900 Mhz machine; the first run likely takes no more than 2 seconds.
-Qs could still be slow, but without some actual numbers, I don't even know what ballpark we're in here. `time pacman -Qs wontfindme` output would be nice here.
Either use a closed ^regex$ as Karol stated if you want exact matches, or give us some timings of the runs of each command so we can see whats up and fix your problem as stated.
-Dan
I agree that looking for a package with that exact name first will not speed up an -Ss operation as the database read is all or none (and is fast anyway). But maybe looking for a package with the exact name of the search term first when doing a -Qs would be an OK thing to do? Also, printing the exact match at the top of the search results may just be a "good thing"... Of course, what I really want to do is move the local DB to being fewer files (I vote tar-based like the sync dbs...) and disk IO speed will not be an issue. Allan
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])) [[ -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
On Thu, Oct 20, 2011 at 3:55 AM, Dave Reisner <d@falconindy.com> 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
On Thu, Oct 20, 2011 at 10:44:18AM +0800, lolilolicon wrote:
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.
Yep, you're correct. We seem to honor the same rules for pkgrel that we do for pkgver, and there's currently a fair number of these "oddities" in the repos (74 in total), a segment of them shown by: $ expac -Ss '%n\t%v' | awk '$2 ~/.*-[[:digit:]]+\..*/' I don't really see any reason we shouldn't explicitly disallow this -- vercmp will do just fine, and the pkgrel is essentially Arch's "local" version for the package. Makes me wonder if anything I've written recently needs to account for this... d
On 20/10/11 12:44, lolilolicon wrote:
On Thu, Oct 20, 2011 at 3:55 AM, Dave Reisner<d@falconindy.com> 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.
Both pkgver and pkgrel can not contain a hyphen. makepkg will error if they do. Allan
participants (6)
-
Allan McRae
-
Dan McGee
-
Dave Reisner
-
Karol Blazewicz
-
lolilolicon
-
Markus Jochim