Am Freitag, 18. April 2008 schrieb Matthias Klose: > postgresql-8.3-pljava-gcj currently directly depends on a specific > version of libgcj, which is unneeded, and doesn't allow the bindings > to work with another jvm. The upstream should be built without setting > USE_GCJ, but by setting JAVA_HOME to /usr/lib/java-gcj and adding > /usr/lib/java-gcj/bin to PATH.
Well, the current approach works, at it does so in the way upstream designed it. What would we gain by changing it? > The name of the binary package is wrong. The package itself contains > jni bindings and has nothing to do with gcj in the first place. Please > have a look at the glib-java package how jni bindings can be packaged: > > - libpostgresql-8.3-pl-java, binary indep, holding the jar file > - libpostgresql-8.3-pl-jni, binary arch, holding the jni bindings > (these two packages could be merged into one). > - libpostgresql-8.3-pl-java-gcj, binary-arch, built using > dh_nativejava (using aotcompile) to optimize performance when > running with the gij runtime. Only this package depends on > libgcj-bc (not on a specific libgcj library package). > See for example the libxerces2-java source how such a package > is built. I think you are confusing the purpose of this package. It is not a Java library, but a PostgreSQL plugin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
