Bug#256283: [pylucene-dev] Re: PyLucence Debian Package
On Fri, 3 Feb 2006, Matthew O'Connor wrote:
Personally, I'm fine with it going into contrib. I'd like
it to go into main but that's probably not feasible unless
there's a DFSG-free JDK that could compile it.
If Java Lucene exists as a Debian package already, then this problem must have
been solved there. The Ant/JDK build of Java Lucene in PyLucene is just a
regular Java Lucene build using their build procedures, except that some of
the .java source files are patched first.
Andi, correct me if I am wrong, but I believe PyLucene has
always required patches to Lucene's source code. This is
the impression I get from the README:
Yes, this is correct. The situation is better now than it has been in the past
as some of the patches were included into the Java Lucene sources but the
remaining ones have no place in the Java Lucene sources and as long as gcj is
bleeding edge, such patches are bound to come and go...
We could wait until Lucene 1.9 is official, that'd be fine.
However, I don't expect that will change things much since
it's my understanding that the issues are mostly with GCJ.
Is that right Andi?
Correct. The current patches are not due to Java Lucene bugs but are due to
gcj, gcjh and javacc bugs or issues.
Andi would know better if waiting for GCJ to mature is a
good idea. In Sept. 2004 Andi seemed to be mildly
optimistic that gcj 3.5.0 would eliminate the need for
patches. See the bottom half of:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256283#msg25
However, that doesn't seem to have panned out. See this
email:
http://lists.osafoundation.org/pipermail/pylucene-dev/2006-February/000815.html
(I'm assuming here gcc 3.5 is more or less the same as gcc 4.0).
I'm currently recommending gcj 3.4.x, with x >= 3 for PyLucene. I've had
little luck with gcj 4.x thus far.
Let me see if I have this suggestion right. The pylucene
source package would include a patched fork of the Lucene
code. Those sources get compiled with Java Lucene's Ant
build using a regular 1.4.2 JDK. This produces a .class
file that we then compile with GCJ.
Once there is a Debian Java Lucene 1.9 source package available, the PyLucene
1.9 package could be made to depend on it, unpack it, apply the patches, build
it (and not install it) and then build itself. Seems pretty straightforward to
me.
So I'm a little vague on where to go from here. In my
opinion your fourth option is the best. If you think it's
wise, I could back off and package the PyLucene 1.0.1 tree
which is based on the Lucene 1.4.3 sources. That'd
side-step the fact that 1.9 is still a release candidate.
What do you say?
Doing this with Java Lucene 1.4.3 instead of 1.9 solves only one problem: Java
Lucene 1.9 is not a release yet. The vibes I get on the Java Lucene dev list
don't make me think that there is any sense of urgency in making such a
release happen even though the Java Lucene 1.9 code as it stands now seems
very ready for it.
Andi..
Reply to: