Created attachment 794749 [details] bind-9.9.3-5.P2.fc19.O0.x86_64.rpm Description of problem: DNF fails with Error: nothing provides /bin/python needed by bind-32:9.9.3-5.P2.fc19.O0.x86_64 although python package is installed. Version-Release number of selected component (if applicable): dnf-0.3.11-2.git54f55e0.fc19.noarch How reproducible: 100 % Steps to Reproduce: 1. On F19 system with python-2.7.5-3.fc19.x86_64 try to install attached package bind-9.9.3-5.P2.fc19.O0.x86_64.rpm. Actual results: Setting up Install Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Error: nothing provides /bin/python needed by bind-32:9.9.3-5.P2.fc19.O0.x86_64 Expected results: Installation works - as with YUM. Additional info: $ rpm -q --whatprovides /bin/python python-2.7.5-3.fc19.x86_64 This doesn't happen if I use bind-32:9.9.3-5.P2.fc19.x86_64 from Koji, but I have no idea why. The only difference is that my package is compiled without optimizations (gcc -O0).
Hi, the attached package is requiring /bin/python but there's no package that explicitly provides this. The package in Koji [1] is installable because it correctly requires /usr/bin/python. DNF works as expected in this case. [1] http://koji.fedoraproject.org/koji/rpminfo?rpmID=4331103
So... Is it a bug in yum? Yum can install this package without a problem.
AFAIK there's no /usr/bin/ magic in Yum, but it's definitely in rpm: $ rpm -q --whatprovides /bin/python python-2.7.3-7.2.fc17.i686 $ rpm -q --list python-2.7.3-7.2.fc17.i686 /usr/bin/pydoc /usr/bin/python /usr/bin/python2 /usr/bin/python2.7 /usr/share/doc/python-2.7.3 /usr/share/doc/python-2.7.3/LICENSE /usr/share/doc/python-2.7.3/README /usr/share/man/man1/python2.7.1.gz
Same problem for me (rhel7 / fedora-20) I'm creating my own package with python binaries. 1/ The automatic dependancy generator will require /bin/python instead of /usr/bin/python. When trying to upgrade python I get the following error: --> Processing Dependency: /bin/python for package: opkgc-2.0.1-2.el7.noarch --> Finished Dependency Resolution Error: Package: opkgc-2.0.1-2.el7.noarch (@oscar_rhel7-x86_64) Requires: /bin/python Removing: python-2.7.5-12.el7.x86_64 (@updates) Not found Updated By: python-2.7.5-16.el7.x86_64 (el7_x86_64) Not found You could try using --skip-broken to work around the problem 2/ Eventhough it requires /bin/python, this shouldn't fail $ rpm -q --whatprovides /bin/python python-2.7.5-16.el7.x86_64 $ rpm -q --whatprovides /usr/bin/python python-2.7.5-16.el7.x86_64 How can this be fixed. I've tried to put Requires: python => No success AutoReqProv: no is not an option (would only hide the problem). Note: my package contains only one python file. This file starts using #!/usr/bin/env python, but when replacing with #!/usr/bin/python, that doesn't help. Problem only occures on systems where /bin is a link to /usr/bin
Hi guys, this is related to the paths in your $PATH variable, for the user who built the package. the $make rpm command reads the variable and uses the first path for generating the string for the Python binary. To solve, edit your $PATH to add /usr/bin before /bin and recreate the rpm. That should solve the issue.
I need to update the $PATH comment #5 a bit, because there's not obvious how $PATH is related to this problem: 1. the 'Requires: /bin/python' or 'Requires: /bin/perl' is usually automatically generated during rpm-build. That's generated based on script shebangs, so if you are using '#! /bin/perl', you'll have '/bin/perl' Requires. Workaround is to use '#! /usr/bin/perl'. 2. If you use autotooled project, and you use AC_PATH_PROG([PERL], [perl]), then your shebang is most likely automatically "detected", and any occurence of @PERL@ in your sources is substituted with detected value. That's where $PATH matters, because the first valid perl binary in your $PATH is substituted. Then fixing $PATH can workaround this issue, but I bet it is correct in Fedora default buildroots in Koji (so either something is re-defined in your *.spec, or it is only issue on developer's box. I'm not aware of other buildsystems, but it might be similar - that's JFTR. The question is why we don't automatically change '/bin/perl' into /usr/bin/perl, or why we at least don't generate a correct Requires automatically. But that's for separate bug not filed by me, I can imagine that this is the right thing to do. [1] http://git.savannah.gnu.org/cgit/automake.git/tree/bin/automake.in?id=455bad28ec7120640750ecfca12ddacce27d5fe8