Description of problem: rpm and dnf behave differently with a "provides" query on an installed file. $ rpm -q --whatprovides /lib64/libXv.so.1.* libXv-1.0.10-2.fc22.x86_64 $ dnf whatprovides /lib64/libXv.so.1.* Error: No Matches found dnf should behave the same way as rpm. As I understand it, rpm does some sort of fingerprinting for installed files. Does rpmlib export that function? https://lists.fedoraproject.org/pipermail/devel/2012-February/161994.html Version-Release number of selected component (if applicable): dnf-1.0.0-1.fc22.noarch
I think it would be quite surprising for dnf's "whatprovides" to act differently depending on whether or not a package is installed. Also note that using wildcards without quotes is a bit dangerous here. You're not asking rpm (or dnf) what provides _anything_ starting with "/lib64/libXv.so.1." -- instead, the * matches /lib64/libXv.so.1.0.0 (or whatever is installed) so you are actually calling "rpm -q --whatprovides /lib64/libXv.so.1.0.0"
Sorry, I wasn't clear about that. I intentionally used a glob that matched local files. The issue came up on the Fedora list, where a user had a corrupt .so file: https://lists.fedoraproject.org/pipermail/users/2015-June/461846.html > error while loading shared libraries: /lib64/libexempi.so.3: file too short rpm has a "whatprovides" query that will indicate which package installed a local file. Because dnf has a command of the same name, it should be expected to provide an equally useful result for the query.
The files created after package installation could be probably saved in system.solv. That means the change in libsolv and means the installed package would have another files that available package. rpm --whatprovide could show what the package actually provides - that would make it consistent with DNF. For figuring out the ownership there is IMO another command (`rpm -fq ...`)
* I mean don't involve symlinks /usr/bin -> /bin stuff etc. in --whatprovides output - print just raw data the package actually provides.
Rpm behaves like this for long time, we don't plan to change this behaviour only to be more consistent with dnf.
To be clear, I wasn't asking for rpm to be made worse, I was asking for dnf to be made better.