Bug 982664

calling rpm gives reasonable results:
[mborzecki@localhost:~]$ rpm -q --whatprovides /bin/python
python-2.7.5-1.fc19.x86_64

Yes, I can reproduce this. Will try to see about a fix.

Note that this never exhibits during resolving, it's strictly limited to the CLI provides lookup interface (i.e. 'dnf provides').

There's no good fix for this as currently there's no packages actually providing anything under '/bin'. For instance, this is the python's package filelist from Fedora metadata:

<package pkgid="be0fdf7df93c4130df28f194982cfef36eefa3c0a073730cd457447518e790f9" name="python" arch="x86_64">
  <version epoch="0" ver="2.7.5" rel="1.fc19"/>
  <file>/usr/bin/pydoc</file>
  <file>/usr/bin/python</file>
  <file>/usr/bin/python2</file>
  <file>/usr/bin/python2.7</file>
  <file>/usr/share/doc/python-2.7.5/LICENSE</file>
  <file>/usr/share/doc/python-2.7.5/README</file>
  <file>/usr/share/man/man1/python.1.gz</file>
  <file>/usr/share/man/man1/python2.1.gz</file>
  <file>/usr/share/man/man1/python2.7.1.gz</file>
  <file type="dir">/usr/share/doc/python-2.7.5</file>
</package>

No /bin/python entries. /bin/python only exists in modern Fedoras because there's a symlink from /bin to /usr/bin. But the packages themselves don't know about it. RPM must use a trick (like transparently translating /bin/* to /usr/bin/*) to do that. Yum does something similar but that fails in the globbing case:

[akozumpl@localhost ~/projects/pytest]$ yum provides '/bi*/python'
Loaded plugins: langpacks, refresh-packagekit
No matches found

yet:
[akozumpl@localhost ~/projects/pytest]$ yum provides '/usr/bi*/python'
Loaded plugins: langpacks, refresh-packagekit
python-2.7.5-1.fc19.i686 : An interpreted, interactive, object-oriented programming language
Repo        : fedora
Matched from:
Filename    : /usr/bin/python

...

I'm thinking about fixing this by only issuing a warning in DNF if the 'provides' argument starts with /bin. The Fedora users should internalize that /bin is just a convenience concept now, not a real directory.

(In reply to Ales Kozumplik from comment #2)
> Yes, I can reproduce this. Will try to see about a fix.
> 
> Note that this never exhibits during resolving, it's strictly limited to the
> CLI provides lookup interface (i.e. 'dnf provides').

That's not entirely true. It may happen that 3rd party packages will have /bin/python in requires. Such as the ones below (these are deps for gbs, installed from tizen tools repo): 
[mborzecki@localhost:~]$ rpm -q --whatrequires /bin/python
git-buildpackage-common-0.6.0git20130329-19.1.noarch
git-buildpackage-rpm-0.6.0git20130329-19.1.noarch

Anyways, I think that /usr/bin vs. /bin should be handled seamlessly (same as yum does) so that 3rd party apps don't break.

(In reply to Maciek Borzecki from comment #4)
> (In reply to Ales Kozumplik from comment #2)
> > Yes, I can reproduce this. Will try to see about a fix.
> > 
> > Note that this never exhibits during resolving, it's strictly limited to the
> > CLI provides lookup interface (i.e. 'dnf provides').
> 
> That's not entirely true. It may happen that 3rd party packages will have
> /bin/python in requires. Such as the ones below (these are deps for gbs,
> installed from tizen tools repo): 
> [mborzecki@localhost:~]$ rpm -q --whatrequires /bin/python
> git-buildpackage-common-0.6.0git20130329-19.1.noarch
> git-buildpackage-rpm-0.6.0git20130329-19.1.noarch

These are simple enough to fix. The python executable is not going to move to /bin/python (has it even been there before UsrMove?).

We should probably update the Packaging Guidelines [1] so deps into /bin are avoided --- what do you think about that idea, Spot?


[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies

I have to maintain that what is asked for in this bug is impossible to reasonably achieve and doesn't really work in Yum either, see example below for a binary that's not installed.

Because this can not be implemented in DNF consistently I opt not to make it pretend it does for certain simple cases. The real fix is abolishing the /bin symlink completely (bug 982947).

I added description of this issue to the DNF documentation [1].

[1] http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-provides-bin-file-does-not-find-any-packages-on-fedora

[akozumpl@localhost ~/repos/yum (master)]$ yum provides /usr/bin/dwm-start
Loaded plugins: langpacks, refresh-packagekit
dwm-user-6.0-5.fc19.x86_64 : Dynamic window manager sources and tools for user configuration
Repo        : fedora
Matched from:
Filename    : /usr/bin/dwm-start



[akozumpl@localhost ~/repos/yum (master)]$ yum provides /bin/dwm-start
Loaded plugins: langpacks, refresh-packagekit
No matches found

(In reply to Maciek Borzecki from comment #4)
> That's not entirely true. It may happen that 3rd party packages will have
> /bin/python in requires. Such as the ones below (these are deps for gbs,
> installed from tizen tools repo): 
> [mborzecki@localhost:~]$ rpm -q --whatrequires /bin/python
> git-buildpackage-common-0.6.0git20130329-19.1.noarch
> git-buildpackage-rpm-0.6.0git20130329-19.1.noarch

Those packages are broken.

> Anyways, I think that /usr/bin vs. /bin should be handled seamlessly (same
> as yum does) so that 3rd party apps don't break.

It's not as seamless as you think. Dependency resolution through directory symlinks like /bin/python only when the provider is already installed, this is true for yum and rpm as well, as Ales already said (while I was writing this :)

*** Bug 1203705 has been marked as a duplicate of this bug. ***