Building the pyraf RPM

It turns out the name of this package is a bit of a misnomer, it is actually all of stsci-python including pyraf, along with urwid (for the time being).

In November of 2010, after upgrading to Fedora 14, I get the following messages when I try to install this rpm. (I yum erased it to allow the upgrade to 14 to continue). 

yum install python-pyraf
Loaded plugins: downloadonly, verify
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package python-pyraf.x86_64 0:2.8-3.fc11_tep set to be installed
--> Processing Dependency: python(abi) = 2.6 for package: python-pyraf-2.8-3.fc11_tep.x86_64
--> Processing Dependency: python-abi = 2.6 for package: python-pyraf-2.8-3.fc11_tep.x86_64
--> Processing Dependency: libpython2.6.so.1.0()(64bit) for package: python-pyraf-2.8-3.fc11_tep.x86_64
--> Finished Dependency Resolution
Error: Package: python-pyraf-2.8-3.fc11_tep.x86_64 (mmt-custom)
           Requires: libpython2.6.so.1.0()(64bit)
Error: Package: python-pyraf-2.8-3.fc11_tep.x86_64 (mmt-custom)
           Requires: python-abi = 2.6
           Installed: python-2.7-8.fc14.1.i686 (@fedora)
               python-abi = 2.7
Error: Package: python-pyraf-2.8-3.fc11_tep.x86_64 (mmt-custom)
           Requires: python(abi) = 2.6
           Installed: python-2.7-8.fc14.1.i686 (@fedora)
               python(abi) = 2.7
           Available: python3-3.1.2-14.fc14.i686 (fedora)
               python(abi) = 3.1
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

The root of the issue here is that with Fedora 14, we have moved from Python 2.6 to Python 2.7. The dependency on python(abi) is a fiction indicating a strict dependency on a python 2.6 system. (This may or may not be a valid limitation, but we are going to look deeper than simply bypassing this.

Take a look at the pyraf 1.8 source rpm

I fetch the source RPM (put together by Tim Pickering back in the days of Fedora 11) and unpack it: 

cd rpmbuild/SRPMS
rpm -i python-pyraf-2.8-3.fc11_tep.src.rpm
After doing this, the SOURCES directory has the following files: 
pyraf-1.8.tar.gz
python-pyraf.spec
stsci_python_2.8.tar.gz
urwid-0.9.8.4.tar.gz
All of these packages are now available in newer versions now.

urwid

This is a python package that supports text console applications. The latest version (0.9.9.1) of urwid is now part of the "fedora" rpm repository and available as the package python-urwid. This was true also under fedora 13, but even then we did not install the fedora package on our machines, but relied on the urwid that was incorporated in the python-pyraf package. We can (and should) now cease keeping this old urwid version and go with the latest version, one less thing to worry about.

pyraf

Pyraf is now available as version 1.9. A version of pyraf (usually the latest) is included as part of stsci_python. This tarball was part of the source RPM, simply because at one time it was available as a newer version than what was bundled in stsci_python. At this point in time this is no longer the case and this is no longer needed.

stsci_python

This is now available as version 2.10. The release notes indicate that it supports Python 2.7-beta, but not yet Python 3.

Just build the SRPM as is under Python 2.7

To allow this, there is one line in the %files section that had a hardwired path for python2.6 which needed to be changed to: 
%{_libdir}/python2.7/site-packages/*
After this, the build goes along just fine, albeit with many compiler warnings (things the pyraf team should fix). The outline of the build is:
  1. unpack stsci_python_2.8
  2. unpack urwid-0.9.8.4 inside the stsci_python tree
  3. erase pyraf (but not pytools)
  4. unpack pyraf-1.8 inside the stsci_python tree
  5. symlink pyraf to pyraf-1.8
  6. cd urwid ; /usr/bin/python setup.py build
  7. cd .. ; /usr/bin/python setup.py build
  8. /usr/bin/python setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT
Once the smoke has cleared, I have a new RPM (python-pyraf-2.8-4.fc14_tjt.x86_64.rpm) I add it to our yum repository, and try installing it via: 
yum clean metadata
yum install python-pyraf
It installs cleanly and we are off to the races, but we have more in mind.

remove the internal urwid package

This is simple. The prior scheme had made urwid part of this package, we just get rid of the old urwid tarball, and remove the lines in the prep section that had unpacked urwid inside the stsci tree (and the lines in the build section that built it). We also add a dependency to the python-urwid package. 
rpmbuild -ba --sign python-pyraf.spec
--add the package to our yum repository
yum clean metadata
yum install python-pyraf
This works fine and pulls in python-urwid.

Build stsci_python_2.10

This includes pyraf-1.9 (the latest version), so we can remove the tarball and the lines that replace it within stsci in the spec file. Things keep getting simpler. They could get complex again if the release a new pyraf without updating the stsci package. I decide to rename the package python-stsci (since that is more accurate). I added python-pyraf to the "Obsoletes" list and this worked perfectly, when the stsci package goes in, the old python-pyraf package gets erased.
Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org