LinuxQuestions.org - Issue creating custom Python 2.7.3 RPM

- Red Hat (https://www.linuxquestions.org/questions/red-hat-31/)

- - Issue creating custom Python 2.7.3 RPM (https://www.linuxquestions.org/questions/red-hat-31/issue-creating-custom-python-2-7-3-rpm-4175448003/)

Issue creating custom Python 2.7.3 RPM

Hello,

I'm in the process of creating a custom Python 2.7.3 rpm for a customer. I've configured it so that the rpm installs to /opt/python2.7.3, adds a new config file to /etc/ld.so.conf.d and symlinks the new python binary to /usr/bin/python2.7.3. So far this all works correctly which is great. However, I also need to install the setuptools egg file and configure it to install packages for 2.7.3 and not 2.4.3 which is what the OS relies on. I've attempted to add a second Source line (Source1) but it never seems to extract the file and place the egg file under BUILD. This causes rpmbuild to error out when it gets to the point to place the egg file under /tmp/ and install it using setuptools-0.6c11-py2.7.egg --prefix=/opt/python2.7.1.

Please see below for my SPEC file.

Code:

#--start constants--

%define version 2.7.3

%define libvers 2.7

%define release 1



Summary: Python 2.7.3 located in /opt/python2.7.3

Name: Python

Version: %{version}

Release: %{release}

License: PSF

Group: Development/Languages

Source0: Python-%{version}.tar.bz2

#Never seems to extract this

#Source1: setuptools.tar.bz2

BuildRoot: %{_tmppath}/%{name}-%{version}-root

BuildPrereq: expat-devel

BuildPrereq: db4-devel

BuildPrereq: gdbm-devel

BuildPrereq: sqlite-devel

Packager: fatkang@fatkang.com



BuildArch: x86_64



Requires: tk >= 8.4



Autoreq: 0



%description

Python is an interpreted, interactive, object-oriented programming

language. It incorporates modules, exceptions, dynamic typing, very high

level dynamic data types, and classes. Python combines remarkable power

with very clear syntax. It has interfaces to many system calls and

libraries, as well as to various window systems, and is extensible in C or

C++. It is also usable as an extension language for applications that need

a programmable interface. Finally, Python is portable: it runs on many

brands of UNIX, on PCs under Windows, MS-DOS, and OS/2, and on the

Mac.



%prep

%setup -q



%build

./configure --enable-unicode=ucs4 --enable-shared --enable-ipv6 --prefix=/opt/python2.7.3



%install

#rm -rf $RPM_BUILD_ROOT

make DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p" CP="cp -p" install

mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d

#mkdir -p $RPM_BUILD_ROOT/usr/local/lib/python2.7/site-packages/

#Create config file for ld

echo "/opt/python2.7.3/lib/" >> $RPM_BUILD_ROOT/etc/ld.so.conf.d/opt-python2.7.3.conf



#Create temporary location to install the setuptools egg file

#mkdir -p $RPM_BUILD_ROOT/tmp/eggs_install

#install -m 700 setuptools-0.6c11-py2.7.egg $RPM_BUILD_ROOT/tmp/eggs_install/setuptools-0.6c11-py2.7.egg



%post

/sbin/ldconfig

ln -sf /opt/python2.7.3/bin/python /usr/bin/python2.7



%postun

rm -rf /usr/bin/python2.7

/sbin/ldconfig



%clean

rm -rf $RPM_BUILD_ROOT



%files

%attr(655,root,root)

/opt/python2.7.3/*

/etc/ld.so.conf.d/opt-python2.7.3.conf

#/tmp/eggs_install/*



%changelog

Any assistance will be much appreciated.

-Kang

Since you posted this in the Red Hat forum I'll assert it's about RHEL and in that case there's a couple of issues:

Quote:

Originally Posted by FatKang (Post 4881425)

This causes rpmbuild to error out when it gets to the point to place the egg file under /tmp/

Minor nit: you have access to all env vars rpmbuild uses like %_buildroot and $RPM_BUILD_ROOT so there's no need to use /tmp.

Quote:

Originally Posted by FatKang (Post 4881425)

I've attempted to add a second Source line (Source1) but it never seems to extract the file and place the egg file under BUILD.

By default rpmbuild emits enough on stdout and stderr to debug simple problems. So if you run your build process as 'rpmbuild -bb /path/to/spec 2>&1 | tee /path/to/spec.log' you have a log file to check. Posting a spec file is nice but post relevant excerpts from the log is really helpful for understanding what really goes on (like not untarring the second tar ball into your build directory ;-p).

Quote:

Originally Posted by FatKang (Post 4881425)

I'm in the process of creating a custom Python 2.7.3 rpm for a customer.

Rpm-using Linux distributions depend on Python and this goes especially for RHEL and the Python version it ships with. "Just" building and replacing that without extensive acceptance testing would be potentially disastrous and a fatal misconception of what RHEL (or your job as admin) stands for IMNSHO.

Quote:

Originally Posted by unSpawn
Since you posted this in the Red Hat forum I'll assert it's about RHEL and in that case there's a couple of issues:
You are correct as this is for RHEL and Centos 5

Minor nit: you have access to all env vars rpmbuild uses like %_buildroot and $RPM_BUILD_ROOT so there's no need to use /tmp.
Are you referring to these lines in the spec file?
#mkdir -p $RPM_BUILD_ROOT/tmp/eggs_install
#install -m 700 setuptools-0.6c11-py2.7.egg $RPM_BUILD_ROOT/tmp/eggs_install/setuptools-0.6c11-py2.7.egg

If so I did that so the rpm could install the egg file with the --prefix= option. I handn't added that in yet since I couldn't even get past the point where
install -m 700 setuptools-0.6c11-py2.7.egg $RPM_BUILD_ROOT/tmp/eggs_install/setuptools-0.6c11-py2.7.egg was to run.
If that caused confusion sorry about that.

By default rpmbuild emits enough on stdout and stderr to debug simple problems. So if you run your build process as 'rpmbuild -bb /path/to/spec 2>&1 | tee /path/to/spec.log' you have a log file to check. Posting a spec file is nice but post relevant excerpts from the log is really helpful for understanding what really goes on (like not untarring the second tar ball into your build directory ;-p).

Ah good idea I'm having a duh moment for not having done that. I'll go ahead and rerun and then post the output contents.

Rpm-using Linux distributions depend on Python and this goes especially for RHEL and the Python version it ships with. "Just" building and replacing that without extensive acceptance testing would be potentially disastrous and a fatal misconception of what RHEL (or your job as admin) stands for IMNSHO.

Perhaps my initial post wasn't very clear but this isn't a drop in replacement. Which is why I'm installing this under /opt/python2.7.3,providing a symlink as /usr/bin/python2.7 to /opt/python2.7.3/bin/python, and installing setuptools so it points to /opt/python2.7.3 (I admit having omitted that from the spec file only confuses the discussion)

//Sorry, had an oops with your reply here :-[

Quote:

Responses are in red.

Please don't do that. Use the vBB [QUOTE][/QUOTE] tags around [QUOTE]what you want to quote[/QUOTE] and post your reply beneath that. It's easier quoting for you and me and you don't need to mess with fonts, colors, sizes or anything else, TIA.

Quote:

Are you referring to these lines in the spec file?
#mkdir -p $RPM_BUILD_ROOT/tmp/eggs_install
#install -m 700 setuptools-0.6c11-py2.7.egg $RPM_BUILD_ROOT/tmp/eggs_install/setuptools-0.6c11-py2.7.egg

No lines like

Code:

#/tmp/eggs_install/*

in the %files section.
*BTW /etc/ld.so.conf.d/opt-python2.7.3.conf shouldn't be in the %files section either as you create it in %post as it won't show in either 'rpm -ql python-2.7.3|grep ld.so.conf.d/', 'rpm -Vv python-2.7.3' or 'rpm -qf /etc/ld.so.conf.d/opt-python2.7.3.conf'.

Quote:

If so I did that so the rpm could install the egg file with the --prefix= option. I handn't added that in yet since I couldn't even get past the point where install -m 700 setuptools-0.6c11-py2.7.egg $RPM_BUILD_ROOT/tmp/eggs_install/setuptools-0.6c11-py2.7.egg was to run.

One thing I'm not clear about is if the egg should be run after Python is successfully installed. If it doesn't then you could untar it in $RPM_BUILD_ROOT/, cd into the directory and 'export PATH=/opt/python2.7/bin:$PATH; /bin/sh ./setuptools-0.6c11-py2.7.egg --prefix=/opt/python2.7.3'. OTOH if it needs to be installed only after successful installation then there's two choices I can see: create a separate package (odd since it's a dependency in only the installation order sense) or make the tar ball contents part of the main Python package (say /opt/python2.7.3/share/lib/setuptools/) and execute as a %postinst...

Quote:

Perhaps my initial post wasn't very clear but this isn't a drop in replacement. Which is why I'm installing this under /opt/python2.7.3,providing a symlink as /usr/bin/python2.7 to /opt/python2.7.3/bin/python, and installing setuptools so it points to /opt/python2.7.3

OK, clear. Even so be careful and test exhaustively as Python b0rkage isn't the kind of fun your clients expect ;-p