PyLucene: How to package libraries that link against OpenJDK libraries?

[Colin Walters]

On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz
<felix.schwarz at 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-61a3ee0d05ff616ef9be2021b489610e036fd932
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.