Bug 283611 - yum search should look into provides
Summary: yum search should look into provides
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F8Target
TreeView+ depends on / blocked
Reported: 2007-09-08 17:25 UTC by Nicolas Mailhot
Modified: 2014-01-21 22:59 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-29 17:40:29 UTC
Type: ---

Attachments (Terms of Use)

Description Nicolas Mailhot 2007-09-08 17:25:12 UTC
-------- Message transféré --------
De: Tom "spot" Callaway <tcallawa>
Répondre à: Discussion of RPM packaging standards and practices for Fedora
À: Discussion of RPM packaging standards and practices for Fedora
Sujet: Re: [Fedora-packaging] Packaging/NamingGuidelines python modules naming
Date: Sat, 08 Sep 2007 13:04:26 -0400

On Fri, 2007-09-07 at 22:03 +0200, Till Maas wrote:
> On Fr September 7 2007, Ville Skyttä wrote:
> > On Friday 07 September 2007, Till Maas wrote:
> > > On Do September 6 2007, Ville Skyttä wrote:
> > > > I would personally call it python-fuse anyway for consistency, and
> > > > perhaps add "Provides: fuse-python = VR", but maybe that's just me.
> > >
> > > Is doing it the other way round not good enough?
> > >
> > > Name: fuse-python
> > > Provides: python-fuse = VR
> >
> > Good enough for whom?  Both of those definitely satisfy the current naming
> Good enough for a user, will there be any differences if one uses yum to 
> search for "fuse-python" or "python-fuse" or will both produce the same 
> result?

I don't think that yum search looks through provides, but I could be
wrong on that. Should be easy enough to test (run repoquery on the one
package, point yum at the new "repo" and run a search).


Fedora-packaging mailing list

Comment 1 Seth Vidal 2007-09-08 22:00:24 UTC
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.

Comment 2 Michel Lind 2007-09-09 14:03:00 UTC
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)

Comment 3 Nicolas Mailhot 2007-09-09 14:07:30 UTC
IMHO yum should just search into non-filename provides by default, and in
filename provides if the right config setting/flag is set.

Comment 4 Seth Vidal 2008-03-12 14:38:16 UTC
Is the 'yum provides' command not good enough here?

Comment 5 Nicolas Mailhot 2008-03-12 15:05:38 UTC
(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

Comment 6 Bug Zapper 2008-05-14 03:12:53 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 7 James Antill 2008-05-28 22:05:33 UTC
 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.

Comment 8 Nicolas Mailhot 2008-05-28 22:22:45 UTC
It will also make yum search significantly more useful. You're trading computer
time for human time. It's not a good trade

Comment 9 James Antill 2008-05-29 02:55:57 UTC
 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.

Comment 10 Nicolas Mailhot 2008-05-29 08:23:00 UTC
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

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.

Comment 11 Jesse Keating 2008-05-29 14:17:00 UTC
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

Comment 12 Nicolas Mailhot 2008-05-29 14:35:29 UTC
That's the technical man workaround. It's totaly illogical and unfriendly for
average users though.

Comment 13 James Antill 2008-05-29 17:40:29 UTC
 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.

Comment 14 seth vidal 2008-05-29 17:52:57 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.