Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#2334 - AND-based package searching for Pacman

Attached to Project: Pacman
Opened by Luke McCarthy (shaurz) - Monday, 07 March 2005, 16:55 GMT
Last edited by Xavier (shining) - Wednesday, 30 July 2008, 12:08 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Xavier (shining)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version 3.2.0
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

In my experience I have found that sometimes it is difficult searching for packages with pacman because it returned /more/ results when I tried to narrow the search by being more specific (i.e. by adding more words).

I have implemented AND-based package searching for pacman. With this modification only results containing all given words are displayed.

See the forum topic:
http://bbs.archlinux.org/viewtopic.php?t=10528

The diff for pacman-2.9.5:
http://www.iogopro.co.uk/contrib/pacman-2.9.5/pacman_and_search.diff

It has been suggested that this could be added as another option. If we have agreement I would request it be integrated as the default option (as it is in the above implementation). Either way, I think it would be great for pacman to have this ability.
This task depends upon

Closed by  Xavier (shining)
Wednesday, 30 July 2008, 12:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in b8e306b73e9b
Comment by M. H. (DerGuteMoritz) - Thursday, 04 January 2007, 19:52 GMT
I second this request, an OR-based search, as it is the default at the moment, is not very useful for exactly the reasons pointed out above. Please integrate this patch! :)
Comment by Luke McCarthy (shaurz) - Friday, 05 January 2007, 00:17 GMT
Ignore the stristr.c, at the time I didn't know it already existed and was called strcasestr :-)

Pacman's code has probably moved on quite a bit (I guess) since I wrote this.
Comment by Aaron Griffin (phrakture) - Friday, 05 January 2007, 00:19 GMT
Yeah, however, the idea should still be straightforward to implement. I will do it, but it will be a tad lower priority than some other things - so if you want, go ahead and shoot me a patch
Comment by Aaron Griffin (phrakture) - Thursday, 31 May 2007, 05:49 GMT
Implemented in my local git tree... Does anyone have a problem with AND based searching?
Comment by Scott H (stonecrest) - Tuesday, 13 November 2007, 06:17 GMT
I like this idea too, I'm constantly having to grep the -Ss results.. what ever happened to it?
Comment by Aaron Griffin (phrakture) - Tuesday, 13 November 2007, 17:17 GMT
I think I lost this. I'm pretty sure it wasn't merged, but it was like a 2 or 3 line change.
Comment by Ben Dibbens (ibendiben) - Thursday, 10 January 2008, 14:28 GMT
In my opinion far better. Make sure word order doesn't matter though.
Comment by Christoph Siegenthaler (Sigi) - Wednesday, 09 April 2008, 13:55 GMT
Any news on this feature request/bug?
Comment by Dan McGee (toofishes) - Thursday, 24 July 2008, 03:08 GMT
Bueller? Bueller?

Old reports are old. Allan & I are doing a cleanup here and this will get closed unless someone provides a patch as it appears none of the current developers want to do it.
Comment by Xavier (shining) - Thursday, 24 July 2008, 09:13 GMT
I am interested by this, but what turns me off is Aaron saying it was a 2 or 3 lines change.
I am not sure exactly how to do it, but just a quick first sight lets me think that the patch would be bigger and more complicated than that.
Comment by Allan McRae (Allan) - Thursday, 24 July 2008, 09:42 GMT
I will call his bluff and say it can't be done in 2-3 lines.

I was thinking you need to set "found=1" at the start of the search, put the search bit in a loop with a "found=0; break" if it is not found. Then test found at the end of the loop. So about 10 lines :D
Comment by Xavier (shining) - Thursday, 24 July 2008, 10:00 GMT
It is right that if you reverse the two loops, it is easier.
1) loop on all packages
2) loop on the targets

That way, it is easier and we can do like you said.
But we lose the nice performance tweak of 726e90dc2c860ee6893df29f9d8cf9c886fdd66d by doing that.

Otherwise what I am thinking about now is to compute just one regexp, doing an AND of all targets, but I am not sure how to do that yet.
And if I find a way, I am not sure it will preserve c7879e77a716edc725858e316ea9d2fa00056d4d (searching for plain strings for handling packages like dvd+rw-tools).

And the last way I see would be something like filtering a result list step by step.
Comment by Xavier (shining) - Thursday, 24 July 2008, 13:06 GMT
Hm I was wrong. Implementing the last way above turned out to be much simpler than I expected.

I also think this new behavior is much more useful.
   0001-Implement-AND-based-pack... (1.4 KiB)

Loading...