On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz
<felix.schwarz(a)oss.schwarz.eu> wrote:
Hi,
I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora
(and EPEL 5), PyLucene with JCC could possibly be included with Fedora.
Wow, JCC is terrifying. Interacting with Lucene via Jython would be...saner =)
But I'm facing some problems writing the spec files, therefore I
did not
submit the packages for a review:
- JCC rpm [1]: include and lflags are set in setup.py which I have to change
so that the file contains the rights paths. How can I get these paths while
avoid these pitfalls:
Fix the upstream setup.py to detect JPackage compatible VM layouts.
Basically the directory /usr/lib/jvm/java has the current default VM.
The algorithm I used in a patch for java-gnome is to check whether
/etc/java/jpackage-release exists, and if so assume a JPackage
compatible layout. You could also just look in /usr/lib/jvm/java too.
a) Do not have to rebuild JCC every time OpenJDK gets a version
bump?
I don't think so, but that's a question for JCC upstream.
b) Use the correct arch? (...lib/i386) - ok that one could be
solved with
some shell scripting in the spec file
Fix the upstream setup.py
c) How to get the correct vm type? On i386 there is a client and a
server
vm. Is there a way I can "just" get the client vm directory (and as a
fallback the server vm)?
Hm, if the project needs to poke at the internal VM libraries I'm not
sure there's a clean way to do that, but an OpenJDK hacker might be
able to give you an answer.
d) JCC uses JNI so the library paths must be set correctly at
runtime.
Unfortunately, the OpenJDK package does not add its paths to
/etc/ld.so.conf.d (did I miss something?) Is there another workaround
besides using rpath (bad, see a) or filing a bug against OpenJDK?
Right now, you should hardcode the paths to the library in your package. See:
http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be202...
Specifically, "If the JNI-using code calls System.loadLibrary you'll
have to patch it to use System.load, passing it the full path to the
dynamic shared object."
For an example of this see
http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/
This is necessary until we get multilib-awareness into OpenJDK upstream.
- PyLucene rpm [2]: Besides the linker search path I have another
problem
with
the version number. PyLucene uses version numbers which are illegal in RPM
such as "2.3.2-1" (sic!). I think the best way to handle it (besides
upstream changing the numbering schema) is just to use "2.3.2.1". Any
objections?
Sounds reasonable.
And last but not least the naming: PyLucene seems pretty clear to me,
it
conforms to the Python packaging guidelines. But what to do with JCC? It is
essentially a python application containing a C++ library which links
against the JDK. Should this be called python-jcc?
Sure.