Experimental slink python and jpython packages

[Matthias Klose <doko@cs.tu-berlin.de>]

Gregor Hoffleit writes:
 > Hi,
 > 
 > I placed new experimental packages of python and jpython on my private 
 > web page, http://www.mathi.uni-heidelberg.de/~flight/debian-private/.
 > 
 > Sorry that I still not managed to put together the proposal for a Debian 
 > Python policy. If you look at the packages, you'll get the idea for a few 
 > modifications that I'd like to make before the slink release:
 > 
 > - /usr/share/python instead of /usr/lib/python1.5
 > - /usr/lib/python1.5 has the architecture-dependent stuff like 
 >   lib-dynload and config (this should probably be /usr/lib/python/).

Back from my vacations, I am not yet up to date ... What was the date
of the code-freeze for slink? Is there time enough to convert all
other packages?

 > Then, there's the question where and how to install Debian Python add-on 
 > packages. I'd like to adopt a mechanism similar to emacen-common, where 
 > every package registers itself with the system. The install-python 
 > program would byte-compile the files for the installed Python systems 
 > (i.e. with "python", with "python -O" and perhaps with "jpython"). IMHO 
 > this is much better than the current python 
 > /usr/lib/python1.5/compileall.py hack that will have to be updated with 
 > every new major release).

I like this idea (but I don't see what needs to be updated with the
current approach). This script shouldn't contain any location, but
information of architecture dependent and independent files.

And: Shouldn't generated files be placed in /var/cache/python?