Description of problem: When installing Tizen development tools I noticed an issue with inconsistent output of dnf provides for binaries in /bin that are symlinks to corresponding binaries in /usr/bin. dnf output: [mborzecki@localhost:~]$ sudo dnf provides /bin/python No Matches found yum output: [mborzecki@localhost:~]$ sudo yum provides /bin/python ... python-2.7.5-1.fc19.x86_64 : An interpreted, interactive, object-oriented : programming language Repo : installed Matched from: Filename : /bin/python Where /bin/python is actuall owned by python package: [mborzecki@localhost:~]$ rpm -qf /bin/python python-2.7.5-1.fc19.x86_64 Version-Release number of selected component (if applicable): dnf-0.3.8-2.git85524ae.fc19.noarch libreport-filesystem-2.1.5-1.fc19.x86_64 python-hawkey-0.3.14-1.git78b3aa0.fc19.x86_64 python-librepo-0.0.4-2.fc19.x86_64 rpm-python-4.11.0.1-2.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. run dnf provides /bin/python - see that there are no matches 2. run yum provides /bin/python - see that matches were found 3.
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. ***