Hide Forgot
Description of problem: I'm creating my own package with python script inside. 1/ The automatic dependancy generator will require /bin/python instead of /usr/bin/python when PATH has /bin before /usr/bin Thus, When trying to upgrade python package 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 AutoReqProv: no is not an option (would only hide the problem). Problem only occures on systems where /bin is a link to /usr/bin Actual results: Requires: /bin/python Expected results: Requires: /usr/bin/python and yum update should not fail eventhough we have Requires:/bin/python instead of /usr/bin/python Additional info: The problem doesn't occure on older system when /bin is not a link to /usr/bin IMHO, there are 2 problems. 1: yum fails to handle Requires:/bin/python. (rpm is able to find that /bin/python is provided by python package 2: rpmbuild AutoReqProv scripts generate a Requires: /bin/python instead of /usr/bin/python based on the actual PATH variable. when I go to the installdir, if I do: find . |/usr/lib/find-requires The scripts correctly returns /usr/bin/python, so it's wired and I don't see where this /usr/bin/python gets transformed to /bin/python..... How to reproduce with the package I build: svn co http://svn.oscar.openclustergroup.org/svn/oscar/pkgsrc/opkgc/trunk opkgc-2.0.1 tar cpvfz opkgc-2.0.1.tar.gz ./opkgc-2.0.1 PATH=/usr/bin:/bin rpmbuild -tb opkgc-2.0.1.tar.gz rpm -qp --requires ~/rpmbuild/RPMS/noarch/opkgc-2.0.1-2.*.noarch.rpm PATH=/bin:/usr/bin rpmbuild -tb opkgc-2.0.1.tar.gz rpm -qp --requires ~/rpmbuild/RPMS/noarch/opkgc-2.0.1-2.*.noarch.rpm What is strange is that when going into the installed files, find . |/usr/lib/rpm/find-requires always return /usr/bin/python whatever the PATH....
Incorrect component. At a guess it should be 'rpm'.
>2: rpmbuild AutoReqProv scripts generate a Requires: /bin/python instead of /usr/bin/python based on the actual PATH variable." Try following steps: $ svn co http://svn.oscar.openclustergroup.org/oscar/pkgsrc/opkgc/trunk opkgc-2.0.1 $ export PATH=/bin:/usr/bin $ cd opkgc-2.0.1 $ ./autogen.sh $ ./configure $ make $ make install DESTDIR=/tmp $ head -1 /tmp/usr/local/bin/opkgc #!/bin/python As you can see after building and installing your script has shebang "#!/bin/python" and that's why rpmbuild creates dependency on "/bin/python", which I think is correct. That shebang is created by autotools or something but not by rpmbuild. >1: yum fails to handle Requires:/bin/python. (rpm is able to find that /bin/python is provided by python package I was able to reproduce this problem with attached packages: $ sudo yum install testA-1-0.fc20.x86_64.rpm $ sudo yum install testB-1-0.fc20.x86_64.rpm $ sudo yum update testA-1-1.fc20.x86_64.rpm Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Examining testA-1-1.fc20.x86_64.rpm: testA-1-1.fc20.x86_64 Marking testA-1-1.fc20.x86_64.rpm as an update to testA-1-0.fc20.x86_64 Resolving Dependencies --> Running transaction check ---> Package testA.x86_64 0:1-0.fc20 will be updated ---> Package testA.x86_64 0:1-1.fc20 will be an update --> Processing Dependency: /bin/testA for package: testB-1-0.fc20.x86_64 --> Finished Dependency Resolution Error: Package: testB-1-0.fc20.x86_64 (@/testB-1-0.fc20.x86_64) Requires: /bin/testA Removing: testA-1-0.fc20.x86_64 (@/testA-1-0.fc20.x86_64) Not found Updated By: testA-1-1.fc20.x86_64 (/testA-1-1.fc20.x86_64) Not found You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest But I wasn't able to reproduce this problem with rpm: $ sudo rpm -Uvh testA-1-1.fc20.x86_64.rpm Preparing... ################################# [100%] Updating / installing... 1:testA-1-1.fc20 ################################# [ 50%] Cleaning up / removing... 2:testA-1-0.fc20 ################################# [100%] So I move this bug to yum.
Created attachment 921766 [details] testing package testA-1.0
Created attachment 921767 [details] testing package testB-1.0
Created attachment 921768 [details] testing package testA-1.1
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Can't check if it's been fixed in fc-21+
I have same problem on CentOS 7.1.1503. For solving it, I write 'PATH="/usr/bin:$PATH"' in front of 'python setup.py build' on spec file.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.