Description of problem: apt-cache supports a --names-only option which is quite useful if you search for a otherwise popular term like "commons" but you want to filter your search to only package names to get reasonable results reference: http://linux.die.net/man/8/apt-cache
this is reasonable, the only problem is proposing the right syntax of 'dnf search' for this case.
any update on this?
No, sorry. This feature has a low priority for now, we may revisit this after dnf is widely accepted as yum replacement in Fedora.
A good idea. As a repoquery power-user, I've been looking into Fedora user issues with "yum search …" recently. Okay, the Yum manual tries to explain how it works, but users still get poor results from their searches because they expect the search feature to be more clever. Users should not need to come up with creative "whatprovides" queries involving lots of asterisks to find anything at all (which is another issue because DNF behaviour differs from Yum). DNF is the opportunity to get rid of some old cruft in Yum search, such as the misleading "all" option. Re: comment 1 > the only problem is proposing the right syntax of 'dnf search' for this case. The first argument (as in "all" in the man page) could be used to toggle between different search strategies, and depending on what the default should be. all : also search in filelists names : only search package names - perhaps URLs too, because they likely contain the upstream name quick : name/summary/description/url only ??? For example: * A user missing "pkg-config" doesn't find it with "dnf search pkg-config" yet and with "dnf search all pkg-config" not either. Only other packages are found. It isn't even found by "dnf whatprovides pkg-config", because unless one queries for specific paths with/without wildcards, that won't be successful. The package name is "pkgconfig" without the dash in there. * Users, who try to build something from source code, also encounter error messages from "configure" scripts complaining about needed packages in pkgconfig naming scheme. Here it gets much more difficult, since "dnf search" is useless when searching for pkgconfig file names. Unless one is intimately familiar with .pc files, their automatic Provides at Fedora and how to search for them. * Those users, who read about "yum search" and are brave enough to give "yum whatprovides" a try, will encounter a less powerful "dnf whatprovides" so far. # dnf whatprovides libtoolize Using metadata from Sun Mar 22 23:13:16 2015 Error: No Matches found # yum whatprovides libtoolize libtool-2.4.2-32.fc22.x86_64 : The GNU Portable Library Tool Repo : fedora Matched from: Filename : /usr/bin/libtoolize Another reason to think about a more powerful default "dnf search" feature.
And, of course, ditching the "dnf search all ..." in favour of separate "search-all", "search-names" commands would be an option.
Why "dnf list" does not work for you?
It only works if you can guess the package name? # dnf list pkg-config Last metadata expiration check performed 1:56:53 ago on Mon Jun 29 16:08:24 2015. Error: No matching Packages to list # dnf list libtoolize Last metadata expiration check performed 1:57:14 ago on Mon Jun 29 16:08:24 2015. Error: No matching Packages to list In short, user tries "dnf search …", fails, then needs to be creative and guess package names so "dnf list …" with some wildcards may be successful. It must be a short match, or else there will be too many packages in the output. [...] Perhaps one needs to tell more users about web based package search engines, such as: https://apps.fedoraproject.org/packages/ It's successful when finding libtoolize: https://apps.fedoraproject.org/packages/s/libtoolize
Is this what was originally requested? I.e. is this what apt-cache --names-only does?
> Is this what was originally requested? No, obviously not, but if there were a names-only search option, "dnf search …" *by* *default* could search more items than what it does so far. Then it would also be successful for "dnf search pkg-config".
Maybe it's just a language barrier but I am not able to follow the logic. Anyway, can you please file another Bugzilla with the request to implement this search which takes into account *similar* words? Or, in case I didn't understand you, whatever is the functionality that enables the command to succeed in the cases described above. Rahul, why "dnf list" does not work for you?
Bugzilla isn't ideal for long discussions. I won't open a separate ticket as I think the problem is a more fundamental one, and comment 1 already mentioned difficulties squeezing a new option into the command/options syntax. It would be necessary to distinguish between search options and keywords. Adding an option to restrict searches to package names is a good idea, but it doesn't fix default "dnf search …" and not "dnf search all …" either. I think that's important when considering adding options. For "dnf list …" to be successful for the use-case Rahul has pointed out, one needs to be creative and use escaped asterisks (or guess the package name). [...] Computer are expected to take over the work of searching. It's simply embarrassing, if "dnf search …" fails and the user needs to come up with alternatives ways to find something, because "dnf search …" _both_ searches too many fields (N+S) _and_ still not many enough fields (%files lists!) to be versatile enough. Examples given before. Opening another ticket will not lead to anything as long as you think everything's fine. It's been too difficult already trying to convince you, i.e. trying to point out why current "dnf search …" is flawed and fails. You've not confirmed the problem yet other than Ales calling the original RFE reasonable. It's not due to language barriers. It's because somebody has decided on "dnf search …" to mimic "yum search …", possibly aiming at shorter response times instead of more helpful search results. Or why else is "dnf whatprovides …" less powerful than "yum whatprovides …"? -> comment 4 [...] # dnf search Audacious Plugins|wc -l 633 Why does it even bother listing every package that _doesn't_ refer to the keyword "Audacious" in N/S at all? User explicitly asked for words "Audacious" and "Plugins". DNF answers "Hey, I've found GCC Plugins. Did you want those?". Some developer has decided for it to be helpful to also show "least relevant results" where "least relevant" often means "irrelevant". Who has decided that searching %summary is more relevant than searching %description? Who has decided that searching %files path lists is completely irrelevant? Along those lines of thought it could first search only in package names and display the results at the very beginning, since user will need to pipe the overlong output to some tool anyway as the beginning is more relevant. ;-)
Names only is just a subset of the possible filtering options. It is common for users to want to filter more than say list and grep can easily do.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The issue is already fixed. See the output bellow with `dnf-4.14.0`: dnf search Audacious Plugins Last metadata expiration check: 2:39:26 ago on Mon 30 Jan 2023 08:22:04 AM CET. ================== Name & Summary Matched: Audacious, Plugins ================== audacious-plugins.x86_64 : Plugins for the Audacious audio player audacious-plugins-exotic.x86_64 : Optional niche market plugins for Audacious audacious-plugins-amidi.x86_64 : Audacious input plugin for MIDI audacious-plugins-jack.x86_64 : Audacious output plugin for Jack Audio : Connection Kit