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?
