Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 982664 - inconsistent 'provides' results
inconsistent 'provides' results
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ales Kozumplik
Fedora Extras Quality Assurance
:
: 1203705 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-09 10:05 EDT by Maciek Borzecki
Modified: 2015-03-19 10:39 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-10 04:43:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Maciek Borzecki 2013-07-09 10:05:13 EDT
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.
Comment 1 Maciek Borzecki 2013-07-09 10:08:41 EDT
calling rpm gives reasonable results:
[mborzecki@localhost:~]$ rpm -q --whatprovides /bin/python
python-2.7.5-1.fc19.x86_64
Comment 2 Ales Kozumplik 2013-07-09 10:58:05 EDT
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').
Comment 3 Ales Kozumplik 2013-07-09 11:29:47 EDT
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.
Comment 4 Maciek Borzecki 2013-07-09 13:09:07 EDT
(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.
Comment 5 Ales Kozumplik 2013-07-10 03:42:50 EDT
(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
Comment 6 Ales Kozumplik 2013-07-10 04:43:29 EDT
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
Comment 7 Panu Matilainen 2013-07-10 05:26:11 EDT
(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 :)
Comment 8 Radek Holy 2015-03-19 10:39:07 EDT
*** Bug 1203705 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.