`dnf provides` expects to be given a full path, which is not a great default as someone using it is unlikely to know the full path and will only know the name of the missing file. To find it, the user must also know that they must add a wildcard or else the file will not be found. For example: dnf provides Qt5PositioningConfig.cmake Last metadata expiration check: 17:51:58 ago on Sat 22 May 2021 03:11:02 PM MDT. Error: No Matches found dnf provides *Qt5PositioningConfig.cmake Last metadata expiration check: 17:51:58 ago on Sat 22 May 2021 03:11:02 PM MDT. mingw32-qt5-qtlocation-5.15.2-2.fc34.noarch : Qt5 for Windows - QtLocation component Repo : fedora Matched from: Other : *Qt5PositioningConfig.cmake mingw64-qt5-qtlocation-5.15.2-2.fc34.noarch : Qt5 for Windows - QtLocation component Repo : fedora Matched from: Other : *Qt5PositioningConfig.cmake qt5-qtlocation-devel-5.15.2-5.fc34.i686 : Development files for qt5-qtlocation Repo : fedora Matched from: Other : *Qt5PositioningConfig.cmake qt5-qtlocation-devel-5.15.2-5.fc34.x86_64 : Development files for qt5-qtlocation Repo : @System Matched from: Other : *Qt5PositioningConfig.cmake qt5-qtlocation-devel-5.15.2-5.fc34.x86_64 : Development files for qt5-qtlocation Repo : fedora Matched from: Other : *Qt5PositioningConfig.cmake Consider dropping the requirement for the wildcard and matching against full paths by default.
I suggest that there is a misunderstanding in usage. In case that you want to search for a file you search pattern must start with `/` or `*/` (*/Qt5PositioningConfig.cmake or /*Qt5PositioningConfig.cmake). The prefix is required for two reason: performance optimization and unexpected results. A lot of strings combined with `*` can match a lot of unwanted results. Are you satisfied with the answer?
Well, not really, sorry. :) This isn't the way searching works in other contexts (even for other CLI tools), so it wasn't an expected behavior to me, nor one that I was able to guess. Neal Gompa had to explain it to me when I asked why the tool seems to be broken. At the very minimum I would expect this usage quirk to be mentioned in `dnf provides --help`.
Good point, we have to improve documentation.
I tried to improve documentation by adding information how file provides are identified. See: https://github.com/rpm-software-management/dnf/pull/1773. Please feel free to comment the pull request.
Thanks, I will take a look.
Hmm, I'm not sure that the very technical text proposed in that MR would have helped me very much. :)
FEDORA-2021-78c5f8c03d has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
The upstream merge request is not yet merged, and even if it was, the wording change proposed wouldn't really help me much. Re-opening.
Please can you propose a documentation change? I will be happy to assist you.
To be honest, I don't think a documentation change alone will be sufficient here. I can think of two changes that would have helped me: 1. Don't only match full paths by default 2. If a search returns no results, display a message telling the user they need to add wildcard characters to perform a substring search If you don't like #1, would #2 be acceptable?
FEDORA-2021-a3a73697b8 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a3a73697b8
FEDORA-2021-a3a73697b8 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a3a73697b8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a3a73697b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a3a73697b8 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Not fixed yet. `dnf provides Qt5PositioningConfig.cmake` still neither produces the expected output, nor displays a message hinting that I need to adjust the formatting of the search term when no results are found.
The patch with a documentation update is in dnf-4.9.0. That is all what we can do for you. Please read a documentation and use the software according it. In case of `Qt5PositioningConfig.cmake` argument we cannot take it and try to modify it with `*/` or directly expect that the argument can be a file in any file path. Because then we will get reports from users who expect and searched for `Qt5PositioningConfig.cmake` as a provide. Also the search in file path is much slower then other operation, therefore our users will be unhappy because DNF requires much more time. We already tried to extend files searches but we got a negative feedback from community. Users uses arguments surrounded by globs ('*something*') then they will get a lot of matches due to match in filesystem and they dislike it (then we put in code the check for '/', or '*/'). I am closing it because we cannot change a behavior of DNF. We provided an explanation (solution) and documentation update was released.
The documentation fix isn't sufficient because it is not written in a way that I understand and also it is not provided at the moment it would be needed. If you can't change the behavior of the software, can you change the "No Matches found" error message to suggest adding a glob to the search term?
I submitted a pull request to clarify the `dnf provides` documentation in a way that would have helped me the first time I encountered this issue: https://github.com/rpm-software-management/dnf/pull/1804
Fixed with https://github.com/rpm-software-management/dnf/commit/bc70d93609a71978e0064eb90384041da38dc8a3