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:
- removal of python-net and python-misc
- instead, a new package python-lib
- python-lib is Architecture: all; it's the architecture-independent part
of python-1.5.1/Lib.
- /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/).
- sitecustomize should be a conffile and therefore live in /etc/python/.
- Not yet done: Change Makefile.pre.in so that it installs in the correct
places.
- Not yet included, the code exists: Build a shared libpython.
The layout with /usr/share/python and /usr/lib/python has many advantages
for Debian, but also a few drawbacks: It makes it impossible to install
two different Debian python versions at the same time (not possible
yet with the current layout; do we really need this ???). It drives us
away from the upstream python layout. Still I think the advantages (much
easier upgrade paths; let the Debian packaging system handle versioned
dependencies) are more important.
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). Then, there's the question where to install
Python add-on packages: e.g. /usr/share/site-python or
/usr/share/python/site-packages (for architecture-independent files)
or /usr/lib/python/site-packages or /usr/lib/site-python or even
/usr/lib/python1.5/site-packages (for architecture-dependent or binary
packages). Finally, how to handle "old-style" packages ?
The snapshots are very much unfinished; the upgrade is not yet really
working, and they'll certainly break some things.
The JPython stuff is quite unfinished, too (sorry, I forgot to copy the
orig file). You see that it depends on python-lib. In fact JPython is the
very one reason that I'd like to have python-lib.
With JPython, there are still a few copyright issues to resolve:
- Guido and Jim Hugunin told me that they want JPython to be Open Source.
- still the license has at least a few very unclear sentences: You have
to notify CNRI if you distribute modified versions of JPython. I had a
short discussion with Eric Raymond, and I understand that he would
accept this clause as Open Source compatible if they e.g. included an
e-mail address that this notification should be sent to.
- JPython includes a non-free Java regex library, OROMatcher. This has
been removed in this experimental package. Therefore, the package has
no regex support.
- JPython won't work yet with kaffe (kaffe is missing BigInt etc.)
- To compile JPython, you need the non-free JavaCC (Java Compiler
Compiler) package from SunSoft, a kind of Java lex. I don't know the
consequences of this. Is this a reason not to include JPython in main ?
Consequently, if we intended to switch over to this new directory layout,
quite a few packages needed to be changed. Still, the changes would be
mostly trivial.
I really would like to introduce these changes with slink.
Glad to hear any comments,
Gregor
