Putting jython up for adoption

[Ben Burton]

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 <pkg-java-maintainers@lists.alioth.debian.org>;
- Matthias Klose <doko@debian.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).

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.