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.
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.
FS#15106 - Allow OR searching
Attached to Project:
Pacman
Opened by Laszlo Papp (djszapi) - Sunday, 14 June 2009, 21:10 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 16 June 2009, 03:58 GMT
Opened by Laszlo Papp (djszapi) - Sunday, 14 June 2009, 21:10 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 16 June 2009, 03:58 GMT
|
DetailsHello!
It would be great if pacman can handle more arguments(e.g. by searching, pacman -Ss avr log). On gentoo it was basic okay, and if i see well yaourt can handle this too. Now, pacman -Ss avr log search like avr AND log, so there isn't any facility avr OR log. I can solve this with pacman -Ss avr && pacman -Ss log command, but this is longer :), and searches in the database more times. Sincerelly, Laszlo Papp |
This task depends upon
Closed by Dan McGee (toofishes)
Tuesday, 16 June 2009, 03:58 GMT
Reason for closing: Won't fix
Additional comments about closing: AND-based searching is the default, and OR-based searching can be accomplished multiple ways.
Tuesday, 16 June 2009, 03:58 GMT
Reason for closing: Won't fix
Additional comments about closing: AND-based searching is the default, and OR-based searching can be accomplished multiple ways.
It don't find avr-related packages before log-related packages, but in mixed result.
So in gentoo: emerge -S avr log -> first x result is avr-related, second y result is/are log-related.
It don't find avr-related packages before log-related packages, but in mixed result.
So in gentoo: emerge -S avr log -> first x result is avr-related, second y result is/are log-related.
pacman searching already takes multiple arguments, but we agreed AND searching was more useful than OR searching when we implemented
FS#2334This request is about reverting that change, I am not fine with that.
The options are either rejecting this request, or finding an option for OR searching and implementing it.
This would not be longer if you wrote a very simple bash function.
And performance should not be a big problem. The number of comparisons during the search is the same.
However, the database would indeed be loaded on each pacman call, but the filesystem cache makes the subsequent loading much faster.
Won't fix?
As far as this bug goes, we have the option of implementing a far more general searching (i.e. regexp) in which case it is probably better opening a new bug report clearly focused on just that. Or we can close this as Won't Fix. Either way, this bug gets closed...
pacman -Ss '(avr|log)'
are both solutions for this. Searching *is* fully regex based, so we shouldn't reinvent the wheel there.