One possibility is for Debian's lucene package to do both javac and gcj compilation. It would provide both a java and native library version of lucene. Then a separate pylucene package would handle swig and creation of the python module. This would have the advantage of making lucene available to C programmers as well as python programmers. So my questions are: 1) Is this a reasonable approach?Using a GCJ-compiled lucene library by embedding it into another non-java system has to be done with care. The GCJ/Java garbage collector doesn't keep track of java objects returned to the embedding system for which there is no reference in the java space. I had to work this around for PyLucene in the SWIG layer.The value of a naked gcj-compiled lucene package is limited as, were it not for the need to patch it (see below), gcj compiling a java package is pretty trivial, and its direct usability, because of the GC issues, dubious.
So it sounds like someone would have to take on the design of a wrapper library that would create a protocol for handling these details. Perhaps the python-specific details could be factored out of the current swig interface.
It would be nice to get PyLucene packaged up in its current form though, rather than waiting for some big refactoring, since it is already quite useful. It's amazing what you can get it to do with a screen or two of code.
So Jeff what can I do? I already build and install pylucene on several Debian machines with every new version but it's been a couple of years since I've made a Debian package. Could you crank one out if I gave you build instructions and dependencies?