Now that I've got Mailman up and running relatively smoothly in "production" mode, I've taken some time to revisit questions primarily involving Python. The Mailman installation I am running has several non-standard lashups and workarounds that really need some cleanup, and Mark Sapiro has convinced me that using Python resources for that work, plus some extensions, is something I ought to consider seriously.
I was aware, when I downloaded the Mailman 2.1.9 sources, that the recommended Python is given as 2.4.3. A trip to the Python site showed that 2.4.4 was the latest in that chain, and strongly suggested the current version, 2.5. Since I was under severe time pressure to get my site up and running, I did fairly simple ./configure, make, make test, and make install runs, which produced a usable installation, ending up with the Python 2.5 version. However, I was aware that the Python 2.5 build was not particularly complete, and there were a few regression tests that failed.
Accordingly, I've audited the Python build situation for both 2.4.4 and 2.5 on Sun Sparc Solaris 9 and 10, using various versions of gcc and Studio 11 (the Sun Solaris devsys, formerly "Forte"). The situtation turned out to be far worse than I had thought, and turned into something of a porting effort.
I'm left with a nagging impression that perhaps I should fall back to Python 2.4.4. I tried to weave my way through the Sourceforge bug tracker to find out whether I was reinventing the wheel and was unable to pull up some bug reports listed in the README's in the Python 2.5 distribution that pertained to problems I was seeing on my builds. Do the Mailman developers have strong feelings about Python 2.4.4 vs. 2.5?
Getting both versions of Python to find needed libraries and include files for such things as Tcl/Tk turned out to be a small matter of reworking the distribution setup.py. Once I realized that Makefiles and environment arguments didn't seem to influence the Python modules invoked during the build process, adding the needed code to the Python modules got results. There were also some minor corrections to existing Python code. It leaves me with a strong impression that I'm sailing in uncharted water.
I'm a bit dismayed to discover that Python 2.5 includes a ctypes extension with a very GNU-specific libfbbi implementation. The only thing I could find to compile it was a local build of gcc 4.1.1. Other versions of gcc, including the gcc 3.4.3 that is included with the Solaris 10 O/S, failed to build this library properly.
My preference is for a build using the Studio 11 devsys. I can live without a working ctypes in 2.5. But considering the basic changes needed to get either 2.4.4 or 2.5 to do something resembling a complete build, I'm concerned about reliability and robustness. Python is a new language to me, and while I'm beginning to get my arms around it, I think that learning it by getting the distribution to build is a strange way to go about this learning.
In short, should I fall back to 2.4.4?
Hank