First, you need to install RPM devtools:
# yum install rpmdevtools
Then setup your local RPM build tree:
$ rpmdev-setuptree
This will create RPM build tree (~/rpmbuild/) in your home directory. Just a reminder – never, ever, under any circumstances, build RPMs as root user. Just a reminder. Obviously, you knew that already, right?
You also want to get and install additional header files and libraries, such as TCL/TK, expat, sqlite, etc, that are used to build some Python components:
# yum install tk-devel tcl-devel expat-devel db4-devel gdbm-devel sqlite-devel
Now we’re ready to start building an RPM. Get the RPM spec file from source build tree and copy it to your rpmbuild/SPECS directory, also copy the tarball to your build directory:
$ wget http://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2 $ tar jxf Python-2.6.4.tar.bz2 $ cp Python-2.6.4/Misc/RPM/python-2.6.spec ~/rpmbuild/SPECS/ $ cp Python-2.6.4.tar.bz2 ~/rpmbuild/SOURCES/
This spec file is slightly broken and if you try building an RPM with it, it most likely is going to fail. So you need to patch it. The proposed patch has been submitted to python bug tracking system in the days of 2.6.1 release, but hasn’t yet been implemented. This patch doesn’t seem to work with 2.6.4 release and needs changing as well.
I have modified original 2.6.1 patch file slightly so that it can be used to build 2.6.4 Python RPM. You download it and apply to the original .spec:
$ cd ~/rpmbuild/SPECS/ $ wget http://www.grenadepod.com/wp-content/uploads/python-2.6.4.spec.diff $ patch python-2.6.spec python-2.6.4.spec.diff
You should be OK to build the RPM now, but it’ll most likely fail with minor rpath-check errors, such as:
ERROR 0001: file '/usr/lib/python2.6/lib-dynload/_bsddb.so' contains a standard rpath '/usr/lib' in [/usr/lib] ERROR 0001: file '/usr/lib/python2.6/lib-dynload/_sqlite3.so' contains a standard rpath '/usr/lib' in [/usr/lib]
Which indicates that some components are using hardcoded library paths. It’s not a big issue and can be ignored. Run build command as this:
$ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba python-2.6.spec
It should now build without any issues and the result is a set of python RPMs:
$ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba python-2.6.spec ... Wrote: /home/pulegium/rpmbuild/SRPMS/python2.6-2.6.4-1gpod.src.rpm Wrote: /home/pulegium/rpmbuild/RPMS/i386/python2.6-2.6.4-1gpod.i386.rpm Wrote: /home/pulegium/rpmbuild/RPMS/i386/python2.6-devel-2.6.4-1gpod.i386.rpm Wrote: /home/pulegium/rpmbuild/RPMS/i386/python2.6-tkinter-2.6.4-1gpod.i386.rpm Wrote: /home/pulegium/rpmbuild/RPMS/i386/python2.6-tools-2.6.4-1gpod.i386.rpm Wrote: /home/pulegium/rpmbuild/RPMS/i386/python2.6-debuginfo-2.6.4-1gpod.i386.rpm ... $
This is it… You now have python RPMs that you can install on your CentOS 5.x server.
I’m planning to create my little own repository, where I’ll put this (and other) packages. For now, you can download python 2.6.4 source RPM if you want to change something in the spec file and rebuild it yourself.
Related posts:
Thank you for the nice write up. Have you tried creating an RPM for 2.7 python? Can I use the same instructions?
You also need to install the
bzip2-develpackage along with the other*-develpackages if you want to get the standard Pythonbz2module. There’s no fatal warning about that module being skipped, just a warning message, which it can get buried in the noise.zlib-develis one you might want to include as well. And those without access to therpmdevtoolspackage can usemkdir -p $HOME/rpmbuild/{SOURCES,SPECS,BUILD,SRPMS,RPMS} echo "%_topdir $HOME/rpmbuild" >>$HOME/.rpmmacrosinstead of the
rpmdev-setuptreecommand.It appears the configure/make/make install go okay but the build fails with the following. I can’t find any other errors than this.
+ rm -f mainpkg.files + find /var/tmp/python2.6-2.6.4-root-dkorz/usr/lib64/python2.6/lib-dynload -type f + sed 's|^/var/tmp/python2.6-2.6.4-root-dkorz|/|' + grep -v -e '_tkinter.so$' error: Bad exit status from /var/tmp/rpm-tmp.34472 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.34472 (%install)Something is not right building on a 64-bit system. lib64/python2.6/lib-dynload is empty; lib/python2.6/lib-dynload has all the .so files. The commands to build mainpkg.files fail due to this. Doing a configure/make/make install results in only {prefix}/lib (no lib64). It seems %{libdirname} is either being set incorrectly or is being used in places it shouldn’t be.
I’m running CentOS 5.4 x86_64 and building Python 2.6.4.
David, you’re right, this only produces 32 bit version. If you need 64 you need to change some build files, so that they point to lib64 instead of lib. I’m working on a patch at the moment, will add it to the page soon, check back in a few days.
What might be required to get the equivalent of make altinstall?
Any progress on the 64 bit version?