Red Hat Bugzilla – Full Text Bug Listing
|Summary:||yum search should look into provides|
|Product:||[Fedora] Fedora||Reporter:||Nicolas Mailhot <nicolas.mailhot>|
|Component:||yum||Assignee:||Seth Vidal <skvidal>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||9||CC:||dcantrell, ffesti, james.antill, katzj, michel, pmatilai, tla|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-29 13:40:29 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Nicolas Mailhot 2007-09-08 13:25:12 EDT
-------- Message transfÃ©rÃ© -------- De: Tom "spot" Callaway <firstname.lastname@example.org> RÃ©pondre Ã : Discussion of RPM packaging standards and practices for Fedora <email@example.com> Ã€: Discussion of RPM packaging standards and practices for Fedora <firstname.lastname@example.org> 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). ~spot -- Fedora-packaging mailing list Fedoraemail@example.com https://www.redhat.com/mailman/listinfo/fedora-packaging
Comment 1 Seth Vidal 2007-09-08 18:00:24 EDT
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 Alexandre Salim 2007-09-09 10:03:00 EDT
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 10:07:30 EDT
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 10:38:16 EDT
Is the 'yum provides' command not good enough here?
Comment 5 Nicolas Mailhot 2008-03-12 11:05:38 EDT
(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-13 23:12:53 EDT
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
Comment 7 James Antill 2008-05-28 18:05:33 EDT
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 18:22:45 EDT
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-28 22:55:57 EDT
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 04:23:00 EDT
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.
Comment 11 Jesse Keating 2008-05-29 10:17:00 EDT
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 10:35:29 EDT
That's the technical man workaround. It's totaly illogical and unfriendly for average users though.
Comment 13 James Antill 2008-05-29 13:40:29 EDT
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 13:52:57 EDT
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.