Bug 283611

search searches
['name', 'summary', 'description', 'packager', 'group', 'url']



if we add provides searching it'll slow down the results b/c of having to search
all the filenames, too.

Would it not be logical to make virtual Provides slightly different from
Provides? The virtual ones are probably more intended for human consumption, and
thus it makes sense to search them.

(This is turning into an RPM question)

IMHO yum should just search into non-filename provides by default, and in
filename provides if the right config setting/flag is set.

Is the 'yum provides' command not good enough here?

(In reply to comment #4)
> Is the 'yum provides' command not good enough here?

Not really, yum provides requires knowing beforehand the package structure, you
typically search for keywords without knowing where they occur in packages

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

 So the reasons not to do this are:

1. It'll make "yum search" significantly slower, which I don't think anyone wants.

2. It won't be obvious why a package has matched (yum info won't show anything
that matches).

...the way to fix #2 is to have something in the description that says "This
package provides the generic smtpdaemon functionality" (or whatever) ... at
which point yum search will find it too.
 For the specific case of python-fuse vs. fuse-python, just dropping something
into the description also seems like the least worst hack.

It will also make yum search significantly more useful. You're trading computer
time for human time. It's not a good trade

 Again, to repeat myself, see reason number #2. If it's that useful to tell the
user something _tell them_ in the description, don't hide user data in
"provides". Then, as a bonus, yum search etc. will find it too.

 And "human time" means accounting for the time the user has to wade through
matches for pulseaudio etc. when they search for 'pipe' ... this is also not a
good tradeoff. As the virtual provides list is ~45k entries on Fed-8, almost all
of which are worthless.

User data is not "hidden" in provides. A very common search pattern is filenames
for example (users just find some page that tells them the name of a binary or
config file and want to get it on their system). 

If we do what you suggest that just means adding an autoprovides script that
copies every manual or generated provides in the package description (no you
don't know beforehand what the user will search exactly, so the ~45k is not
worthless at all. Most users are not developpers that know beforehand almost
exactly the package name they need and only use the search to refine this info).
This will massively bloat metadata, and won't be any faster than searching in
provides.

Searching just on description and expecting packagers to put the right keywords
there is like hoping manual keyword tagging of the internet would work better
than indexing page contents.

Searching is the wrong action when you have hte path to a file.  Just yum
install that path, or for information, yum resolvedep /path/to/file

That's the technical man workaround. It's totaly illogical and unfriendly for
average users though.

 Yes, as I said, it is illogical and unfriendly to be listing huge numbers of
packages on a search just because they have a file or a directory that happens
to match what you typed.
 45k was just for virtual provides, if you include files too you are talking
about an additional 165k _directories_ (roughly 530k file paths).

 You are asking for a huge speed hit to all searches and likely a huge increase
in the returned number of "matching" packages for any search. Both of which will
make search much less usable.

It's been fun watching you two flip the bug back and forth. I thought I'd chime
in a bit here.

1. putting it in yum is probably not going to happen. We just spent a fair bit
of time making it fast - and I'm not sure how much users are aided by this
2. however, yum-plugins offer you the ability to add base commands. Putting in a
'search-all' or  a customizable search would be not very hard and it would be a
good way for you to guage the user interest in such a feature. If you'd like to
write this Nicolas I think it would be pretty useful to see.