Effectively the situation involves these factors:
- distcc-pump ships python modules (.py) and extensions (.so)
- the extensions are only compiled for one python version
- installed using distutils
- distcc-pump is a bash script which calls the modules directly
('python /path/to/include_server.py')
- upstream includes a kludge that uses PYTHONPATH to set the location
of the extension (.so)
These factors combine to cause the repeated breakage and difficulties
with this package.
The previous attempts to fix this (both Debian and Ubuntu) is merely
to update the PYTHONPATH kludge for whatever path is *presumed* the
extensions will end up. This of course breaks as the supported and
default python versions change.
The solution, IMO:
- extension is compiled for all supported python versions OR load with
'python2.N' instead of 'python'
- distutils amended to use --install-format=deb (may not be required)
- remove PYTHONPATH kludge
- bash script should call, e.g., 'python -m
include_server.include_server -c Main()'
- magic (?)
Due to scheduling today I hope to have a patch for this late this
evening. The issue has already proved quite involved (my hopes of a
one-line fix were smashed.. several times !)
Otherwise, I guess that 'python /path/to/include_server.py' suggests
that these modules are considered private and should really be
installed to /usr/{share,lib}/distcc-pump/include_server.py, etc. and
called directly as '/usr/share/distcc-pump/include_server.py'
(requires fix to #!, which is hard-coded python2.4)
There is also a new upstream release since late 2011.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
