Bug 1005235

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