Bug 1197054

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 ***