Bug 963140 - [rfe] names only option for search
Summary: [rfe] names only option for search
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Jaroslav Rohel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-15 08:44 UTC by Rahul Sundaram
Modified: 2019-07-24 11:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Rahul Sundaram 2013-05-15 08:44:17 UTC
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

Comment 1 Ales Kozumplik 2013-05-15 09:11:22 UTC
this is reasonable, the only problem is proposing the right syntax of 'dnf search' for this case.

Comment 2 Rahul Sundaram 2014-07-22 17:31:51 UTC
any update on this?

Comment 3 Jan Zeleny 2014-11-21 12:00:01 UTC
No, sorry. This feature has a low priority for now, we may revisit this after dnf is widely accepted as yum replacement in Fedora.

Comment 4 Michael Schwendt 2015-03-24 10:16:41 UTC
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.

Comment 5 Michael Schwendt 2015-03-24 10:20:33 UTC
And, of course, ditching the "dnf search all ..." in favour of separate "search-all", "search-names" commands would be an option.

Comment 6 Radek Holy 2015-06-29 15:57:43 UTC
Why "dnf list" does not work for you?

Comment 7 Michael Schwendt 2015-06-29 16:09:43 UTC
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

Comment 8 Radek Holy 2015-06-29 16:17:18 UTC
Is this what was originally requested? I.e. is this what apt-cache --names-only does?

Comment 9 Michael Schwendt 2015-06-29 17:52:02 UTC
> 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".

Comment 10 Radek Holy 2015-06-30 06:38:33 UTC
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?

Comment 11 Michael Schwendt 2015-06-30 09:05:05 UTC
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. ;-)

Comment 12 Rahul Sundaram 2015-11-18 05:37:10 UTC
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.

Comment 13 Fedora Admin XMLRPC Client 2016-07-08 09:25:38 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


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