Bug#315289: Putting jython up for adoption
Last night I formally put the jython package up for adoption (#315289).
The reasons are because my time is rather more constrained than it used
to be, and because I have increasingly little to do with java these
Since jython is a non-trivial piece of software, it seems worthwhile
outlining things that the new maintainer should know.
There are two parties with a specific interest in jython:
- The java maintainer group <email@example.com>;
- Matthias Klose <firstname.lastname@example.org>, who looks after cpython.
If you have plans to adopt jython, it is worth contacting these parties
(and in fact I'd prefer them to have first pick at the package if they'd
like to adopt it or co-maintain it themselves).
There are several issues that the prospective jython maintainer(s)
should know about, which the rest of this mail will outline. If you
have any questions at all, please feel free to mail me.
In a similar vein, if you find something strange or unusual in the
packaging, please do mail me and ask if there is a reason behind it. If
you just say "bah, what was he thinking" and get rid of it, there is a
chance you are re-introducing an error / licensing problem / whatever.
It's entirely possible I was just being peculiar, but it's best to write
and ask. (I realise this sounds condescending, but I have had people
break packages like this several times before in the KDE arena, hence
Since I began packaging jython I have insisted on jython staying in
main. This is the reason behind several of the peculiar packaging
practices, since keeping jython in main was somewhat more difficult
in 2001 than it is nowadays.
Some parts of the jython sources have been excluded from the build
(since they rely on non-free/contrib libraries). The most prominent
disabled components are the database classes, which rely on JDBC
drivers that were non-free/contrib until just a couple of months ago.
Now that libpgjava and libmysql-java have moved to main, the database
classes probably deserve another look.
2. Python Version
Since jython is an implementation of python, it shares many of the
same core modules. Rather than ship duplicates, I chose to depend
on cpython and massage jython's path to use modules from there.
(Note that jython still ships its own version of those modules that
need jython-specific tweaking.)
The result of all this is that the version of jython is strongly tied
to the version of its cpython dependency. In particular, jython 2.1
(the current version) still depends on python 2.1.
Upstream is active but very slow. I believe they are working towards
a 2.3 or 2.4 implementation but this is not expected for some months
yet. Upstream has also missed ETAs by a _long_ way before, so please
don't come in expecting anything soon.
The current version (2.1) was released in late 2001. There was
an alpha 2.2 release a couple of years ago, but I opted not to upload
an alpha release to debian (and I'm thankful that I didn't, since
this was never followed by a beta or final version). There have been
no other releases since then, though upstream is still working on it
(i.e., upstream is not dead).
I know that Mathias Klose and others are wanting to finally remove
cpython 2.1 from debian. This would require one of two things:
- waiting on a new jython release;
- shipping duplicates of the python modules in jython and removing
the cpython dependency.
Note that removing the cpython dependency (and eventually removing
python2.1) also raises issues for jython's current support of
3rd-party packages in /usr/lib/python2.1/site-packages.
Currently the jython packages build from Makefiles. This is
primarily because ant was not in main when jython was packaged,
and it's mainly been debian revisions since then (if it ain't
broke, don't fix it, etc).
Upstream certainly has better support for ant than it has for
Makefiles, and it probably makes sense to change to an ant build for
the next upstream release.
4. Readline / Editline Linking
Jython includes an optional component for enabling readline support.
Unfortunately jython also includes code under the old python license
that was (arguably) not GPL-compatible. Even when jython eventually
releases a new upstream version, I fully expect that this will still
be GPL-incompatible (within the jython license soup, the "JPython
Software License" uses the same GPL-incompatible clause).
The library that enables readline support for jython is
libreadline-java. Upstream for that library and myself have put a
fair amount of effort into making that library work with libedit2,
which is BSD and hence not a problem.
The magic key in the jython registry is "python.console.readlinelib",
which defaults to "Editline" in org/python/util/ReadlineConsole.java.
You may need to keep an eye on this for new upstream releases, since
jython upstream seemed somewhat less fussed about this license
incompatibility than I was.
5. Command-Line Utilities / Registry
Jython ships with trivial jython/jythonc scripts by default; I am not
using those at all. These are replaced with more complex perl/shell
scripts in the jython/debian/ directory that massage jython into the
debian environment and hook it up with cpython before it is run.
6. API Documentation
Currently the API documentation is included verbatim in the package
sources (i.e., it's not rebuilt from scratch). This is mainly
because it was all done before gjdoc even existed in debian.
I'm not sure how good gjdoc is these days; you might well be able to
rebuild the documentation now as part of the package build.
Anyway, that's all that comes to mind just now. Again, although I don't
have time to maintain this package any more, I'm still more than happy
to join discussions about it or answer any questions that you might have.