Description of problem: When an attempt is made to build a package containing python code, rpm steps in and runs a script called /usr/lib/rpm/brp-python-bytecompile. rpmbuild then tries to add a dependency on python in the form of a hard dependency on /usr/local/bin/python. Any attempt to install the resultant rpm fails, as /usr/local/bin/python does not exist. (The package that contains python code is a java application running python through jython, and so no dependency on python is necessary or desired). Version-Release number of selected component (if applicable): rpm-build-4.4.2.3-9.el5 How reproducible: - Create a spec file for a package containing python code, but do not depend on python. - Build the package and try to install it: error: Failed dependencies: /usr/local/bin/python is needed by package-0.0.0.noarch
Remove executable bits from the python-for-jython files, that'll make rpm not look at their dependencies. Or alternatively patch the source to refer to #!/usr/bin/python but as it's intended for jython, the first option is probably the more correct one here. This is standard rpm behavior, not a bug.
Patch what source to refer to /usr/bin/python? RPM takes it upon itself, when it encounters python code, to add a broken dependency on /usr/local/bin/python. RPM must be fixed.
There's at least one executable script in your package which starts with #!/usr/local/bin/python Finding which one(s) is not hard. Either the script is intended to run with python or its not. If it is, then the path should be fixed to match what exists on the system. If not, then the shebang line is *wrong* and should be removed. Or like said, you can disable automatic dependency extraction by making the script non-executable in %install. There is nothing to fix in rpm in this case.
The code being RPM'ed is provided by a vendor, and changing their code is not an option for us. We have tried many different ways of completely disabling the entirely unnecessary python processing in the spec file, but have not yet found a way to do so that actually works. Until this problem is fixed, this bug remains.
The Redhat people came back to us with a workaround: Add "Autoreq: 0" to the spec file, and the auto-dependency checking is disabled.
As you see, this is a packaging issue, not a bug.
I had to invoke the big expensive corporate support contract in order to learn of the Autoreq feature, which rpm makes no effort to show is there, unlike the other scripts that rpm applies to the package, which are clearly labeled during the build. Had rpm prefixed the entries with "Autoreq" or something similar, it would have given me something I could have put into google, and this problem would have been avoided.