[pylucene-dev] Re: PyLucence Debian Package
vajda at osafoundation.org
Fri Feb 3 17:57:24 UTC 2006
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:
> However, that doesn't seem to have panned out. See this
> (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
> 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.
More information about the pkg-java-maintainers