Your message dated Mon, 11 Jul 2011 23:54:00 +0200
with message-id <[email protected]>
and subject line Re: Bug#476658: postgresql-pljava - direct dependencies on
libgcj and misleading package name
has caused the Debian Bug report #476658,
regarding postgresql-pljava - direct dependencies on libgcj and misleading
package name
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
476658: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476658
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: postgresql-pljava
Version: 1.4.0-1
Severity: important
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.
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.
--- End Message ---
--- Begin Message ---
Re: Peter Eisentraut 2008-07-02 <[email protected]>
> 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.
IMHO Peter is right here, this is not a bug.
Christoph
--
[email protected] | http://www.df7cb.de/
signature.asc
Description: Digital signature
--- End Message ---
