Python RPM I built won't install

Question

Because I have to install multiple versions of Python on multiple Oracle Linux servers which are built via a kickstart process, I wanted to build a python rpm for our yum repository. I was able to build Python manually using 'make altinstall' which doesn't install over your default system Python installation, so I thought that would be the way to go.

After much trial and error, I managed to build an rpm starting with a .bz2 python 2.7 package - but now when I try to install it, I get an error:

error: Failed dependencies:
    /usr/local/bin/python is needed by Python-2.7.2-1.i386

What the...??? Python is what I'm trying to install!!! And system default Python (2.4) is in /usr/bin/python!!! And my prototyping location for the python directory is /tmp/python2.7 (and the executable was /tmp/python2.7/bin/python2.7). So why is it looking in /usr/local/bin?

Here is the core of my RPM SPEC:

%prep
%setup -q

%build
./configure --prefix=/tmp/python2.7
make

%install

make altinstall

I take a closer look at the rpm build log and I see:

Requires: /bin/sh /tmp/python2.7/bin/python2.7 /usr/bin/env /usr/local/bin/python libc.so.6 libc.so.6(GLIBC_2.0)...[a lot more...]

Ok, so there's where /usr/local/bin comes in... Now, the question is, how is it determining these requirements? Did I specify something wrong? Do I need to override something?

Like many rpm newbies, I get the build part, but I don't really "grok" what happens at the end of rpmbuild and what actually gets put into the rpm file (other than the files you specify in %files) and then what actually happens when you do the rpm install.

Can anyone suggest why my install is failing or what I might read to understand why my rpm build is requiring what I'm trying to build?

Neglectful

Answer 1

You should be able to fix this issue by adding the following line to your spec file:

AutoReq: no

Here is my understanding of why this is necessary. When rpmbuild runs across .py files with a #! (shebang) it will automatically add the binary that the shebang specifies as a requirement. Not only that, if the shebang is #!/usr/bin/env python, it will add a dependency for whatever that resolves to (first python on $PATH).

You either need to turn off the automatic requirement processing or find all shebangs that will cause problems and change them to something else.

Kenwood

You don't want to turn off dependency processing in this case. This may break the python package because RPM won't know what so files the package depends on. The correct thing to do is patch the file containing the erroneous shebang line. – Medford

In most cases I would agree, but this isn't some arbitrary RPM containing Python scripts, it is a Python installation (where the binary will be installed to /usr/local/bin). – Kenwood

That doesn't matter. RPM will still be unable to process dependencies correctly if you disable this feature. – Medford

To keep proper dependencies while also using AutoReq: no option, copy the Requires: output from rpmbuild during the successful build, paste into the .spec file, and rebuild. Just make sure to remove the troublesome parts (such as /path/to/python) from the Requires list. Then, the required libraries etc will be checked for, but the provided python executable(s) will not be. – Exuviae

Answer 2

rpmbuild can get pretty smart and this is one of those cases. It probably pulled the /usr/local/bin/python from one of your script files containing something like:

#!/usr/local/bin/python

at the top. Try grep'ing for this path in the files within your bz2 file.

Sideswipe

There are two -- however, I don't want to muck with the sources if I don't have to since %setup is unpacking them from the original downloaded file -- is there any way around this issue? – Neglectful

This is the correct answer. In the python source code, there is a file with the shebang line containing /usr/local/bin/python. @Ilane, the correct thing to do is write a patch to the source code. A standard part of building RPMs is writing patches. You will note in the file containing the offending shebang, there is a comment to the effect that python packagers will need to write a patch if they do not install python to /usr/local. – Medford

Specifically the problem is cgi.py. The Fedora specs (python 3, python 2) fix this by running Tools/scripts/pathfix.py. – Mog

@SamHartsfield Thanks! Links have atrophied a bit; python3 is here and python2 is no longer maintained. – Gage