distributing own python, cross-linux

Question

I have the following problem. I need to distribute our own version of python with some magic in it. In order to do this, the process is the following:

1. I build the python interpreter (on a redhat linux)
2. install it somewhere
3. tar.gz the whole thing
4. when it's time to make the user-package, unpack the tar.gz into the directory which will become the user package
5. tar.gz the user package directory
6. put the tar.gz on the web

This is the method I have to use. Good, bad? I don't know, I have little experience as a packager, and in any case I can't propose a change. This is the way they always did.

It turns out that when the user unpacks this tar.gz on suse, and tries to run the python setuptools (which has been installed together with python), the hashlib module raises an exception. What I found out is that building python on redhat, the python configure script finds the openssl library, which in turns makes it skip the building of the shamodule.c, md5.c and so on, and compiles hashmodule.c to attach to the openssl library. apparently, the openssl 0.9.7 on suse and the 0.9.8 on redhat are somehow different, meaning that, for some reason, the _hashlib module, when imported on suse, raises an import error, leading hashlib try to import _md5, _sha, _sha256, which are not there because on the redhat there was no reason to compile them (since openssl was jolly good there).

Does anyone know how to solve this problem. As I said, my experience as a packager is the bare minimum, so any hint and proposal are welcome, and I will try to deploy it as much as I am allowed by our legacy.

Answer 1

Does anyone know how to solve this problem.

You can't, really. If it's not the OpenSSL library that's a problem, it could be the C library itself, or some other critical component. Your best solutions are either:

(A) Build a version of Python for each operating system you wish to support, or

(B) Rework your code to use the native system Python on each platform.

Your alternative is to create a completely self-contained build environment so that when building under RedHat you're not using the system OpenSSL library, but are instead using one that you built yourself. This will work for just about everything other than the C library, but it can be tricky to set up. The idea is to minimize the relationship between your package and the system libraries.

If you're only supporting RedHat and SUSE, you could conceivably pursue option (A) by crafting an appropriate spec file and building binary packages for each platform. This would be a nice way to package everything up.

Answer 2

You should consider distributing a source RPM of your version of Python, rather than a binary tarball. You can take an existing Python release and repackage it with a patch of your changes. There's more detail on how to do this in the RPM Book.

• CurtisB: There's no way to support multiple Linux platforms with a single binary image, unless it's statically linked to include all dependencies. Even then, you would run into issues on platforms with newer or older kernels.