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 days.
Since jython is a non-trivial piece of software, it seems worthwhile outlining things that the new maintainer should know. Interested Parties ------------------ There are two parties with a specific interest in jython: - The java maintainer group <[EMAIL PROTECTED]>; - Matthias Klose <[EMAIL PROTECTED]>, 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). Packaging Issues ---------------- 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 the note.) 1. Freeness 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. 3. Makefiles 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. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]