Description of problem: $ sudo dnf repoquery --whatprovides '/usr/bin/enum' [sudo] heslo pro vondruch: Using metadata from Wed Feb 25 10:39:29 2015 $ sudo dnf repoquery --whatprovides '/usr/bin/ps' Using metadata from Wed Feb 25 10:39:29 2015 procps-ng-0:3.3.10-4.fc21.i686 procps-ng-0:3.3.10-4.fc21.x86_64 procps-ng-0:3.3.10-5.fc21.x86_64 procps-ng-0:3.3.10-5.fc21.i686 Compared to plain repoquery: $ repoquery --whatprovides '/usr/bin/enum' rubygem-spruz-0:0.2.5-10.fc21.noarch enum-0:1.1-6.fc21.x86_64 $ repoquery --whatprovides '/usr/bin/ps' procps-ng-0:3.3.10-5.fc21.i686 procps-ng-0:3.3.10-5.fc21.x86_64 procps-ng-0:3.3.10-4.fc21.i686 procps-ng-0:3.3.10-4.fc21.x86_64 This might be related to bug 1190991 although in this case, the query for '/usr/bin/ps' should not return anything. Version-Release number of selected component (if applicable): $ rpm -q dnf-plugins-core dnf-plugins-core-0.1.5-1.fc21.noarch
Hello, AFAIK the difference is that "procps-ng" contains explicit provide of the binary while neither "rubygem-spruz" nor "enum" does. To make it work as you expect, bug 1190991 needs to be resolved. So, let me close this as a duplicate. *** This bug has been marked as a duplicate of bug 1190991 ***
I thought so, but then DNF must be doing some strange magic: $ rpm -q --provides procps-ng | grep bin/ps /bin/ps $ rpm -ql procps-ng | grep bin/ps /usr/bin/ps i.e. there is explicitly: Provides: /bin/ps in .spec file, but how is this matched to /usr/bin/ps is miracle to me.
Right, this is weird. OK, we'll take a look.
Looks like rpm --provides is giving preference to /bin/binary file ignoring /usr/bin/binary. I just added one of my simple package following and built it Provides: /bin/binary Previously provides showing /usr/bin/binary and after adding above in spec file now it shows /bin/binary
How it basically works (let's take grep for example): # rpm -qf /etc/system-release fedora-release-21-2.noarch # rpm -ql grep | grep bin /bin/egrep /bin/fgrep /bin/grep # rpm -qf /bin/grep grep-2.20-6.fc21.x86_64 # rpm -qf /usr/bin/grep grep-2.20-6.fc21.x86_64 # ls -ld /bin /usr/bin /usr/bin/grep lrwxrwxrwx. 1 root root 7 Aug 16 2014 /bin -> usr/bin dr-xr-xr-x. 2 root root 36864 Feb 20 11:42 /usr/bin -rwxr-xr-x. 1 root root 158944 Nov 14 17:39 /usr/bin/grep So, although package installs grep binary into /bin (and this is recorded in rpm database) which is link to usr/bin the binary physicaly ends in /usr/bin/grep. And rpm is able to deal with it. Yum does similar magic: # yum provides /bin/grepgrep-2.20-6.fc21.x86_64 : Pattern matching utilities ... Repo : fedora Matched from: Filename : /bin/grep grep-2.21-2.fc21.x86_64 : Pattern matching utilities Repo : updates Matched from: Filename : /bin/grep grep-2.20-6.fc21.x86_64 : Pattern matching utilities Repo : @anaconda Matched from: Filename : /bin/grep # yum provides /usr/bin/grep ... grep-2.20-6.fc21.x86_64 : Pattern matching utilities Repo : @anaconda Matched from: Filename : /usr/bin/grep See the difference - /bin/grep is found in couple of available packages because this path is hardwired in package but /usr/bin/grep is found only in installed package. And now dnf: # dnf provides /bin/grep grep-2.20-6.fc21.x86_64 : Pattern matching utilities Repo : @System grep-2.20-6.fc21.x86_64 : Pattern matching utilities Repo : fedora grep-2.21-2.fc21.x86_64 : Pattern matching utilities Repo : updates # dnf provides /usr/bin/grep Error: No Matches found It does no magic so it has no clue what /usr/bin/grep is. And the crucial question here is: Do we want mimic rpm's and yum's behaviour or not? ;)
If I understand this correctly: http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#dnf-provides-bin-file-does-not-find-any-packages-on-fedora DNF should even behave the other way. It should work for "/usr/bin/grep" but not for "/bin/grep". But maybe it applies only to packages that has "/usr/bin/foo" in the "%files" section. Well, I reopened the bug because there is something strange in what DNF does with "Provides:" tags, not with the fileprovides. The Michael's example above does not provide an answer to what DNF does because it's only about fileprovides which "dnf repoquery" does not take into account now. If we resolve bug 1190991, it won't be interesting any more. So, there are two options. We would either focus on what happens with the Provides now or we would close this as it does not matter after resolving the mentioned bug.
*** This bug has been marked as a duplicate of bug 1196952 ***