-------- Message transféré -------- De: Tom "spot" Callaway <tcallawa> Répondre à : Discussion of RPM packaging standards and practices for Fedora <fedora-packaging> À: Discussion of RPM packaging standards and practices for Fedora <fedora-packaging> 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 Fedora-packaging https://www.redhat.com/mailman/listinfo/fedora-packaging
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.