i think this package has a misused case of DEPEND vs RDEPEND. This is whats installed with USE="java" sys-libs/db-4.1.25_p1-r3 * CONTENTS: /usr /usr/include /usr/include/db4.1 /usr/include/db4.1/cxx_common.h /usr/include/db4.1/cxx_except.h /usr/include/db4.1/db.h /usr/include/db4.1/db_185.h /usr/include/db4.1/db_cxx.h /usr/lib /usr/lib/libdb-4.1.so /usr/lib/libdb-4.1.la /usr/lib/libdb_cxx-4.1.so /usr/lib/libdb_cxx-4.1.la /usr/lib/libdb_java-4.1.so /usr/lib/libdb_java-4.1.la /usr/lib/libdb_tcl-4.1.so /usr/lib/libdb_tcl-4.1.la /usr/lib/libdb-4.1.a /usr/lib/libdb_cxx-4.1.a /usr/lib/libdb_java-4.1.a /usr/lib/libdb_tcl-4.1.a /usr/lib/libdb.so -> libdb-4.1.so /usr/lib/libdb_cxx.so -> libdb_cxx-4.1.so /usr/lib/libdb_tcl.so -> libdb_tcl-4.1.so /usr/lib/libdb_java.so -> libdb_java-4.1.so /usr/lib/libdb.a -> libdb-4.1.a /usr/lib/libdb_cxx.a -> libdb_cxx-4.1.a /usr/lib/libdb_tcl.a -> libdb_tcl-4.1.a /usr/lib/libdb_java.a -> libdb_java-4.1.a /usr/lib/db-4.1.jar /usr/bin /usr/bin/db4.1_deadlock /usr/bin/db4.1_dump /usr/bin/db4.1_load /usr/bin/db4.1_printlog /usr/bin/db4.1_recover /usr/bin/db4.1_stat /usr/bin/db4.1_verify /usr/bin/db4.1_archive /usr/bin/db4.1_checkpoint /usr/bin/db4.1_upgrade /usr/sbin /usr/sbin/berkeley_db41_svc /usr/include/db.h -> db4.1/db.h /usr/include/db_185.h -> db4.1/db_185.h Nothing here seems to require the RDEPEND of jdk. DEPEND="tcltk? ( dev-lang/tcl ) java? ( virtual/jdk )" I'd suggest a change here to be: DEPEND="tcltk? ( dev-lang/tcl ) java? ( virtual/jdk )" RDEPEND="tcltk? ( dev-lang/tcl ) java? ( virtual/jre )" As this would fit better for end user systems.
You are probably correct. I'll change it
i dont agree with this change to compile the java part of db, you need a jdk not a jre.
The dependency will require a jdk when compiling, but only a jre when running (allthough it probably does not make that much sense as as far as I know, there are no packages that actually use the db java bindings (so a jdk would be needed anyway).
Well here's the logic: all jdk's provide a jre. to build this you need a jdk. To build something against this, you need a jdk. To use this, you need a jre. (Well, not really?) To use something built against it, you need a jre.
It's not quite true. A JDK or a JRE is not strictly required. GCC is sufficient in order to build db 4 with java flag enabled. Here is the procedure with gentoo 2004.0, gcc with java support enabled: USE=java emerge gcc ln -s /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include \ /usr/i686-pc-linux-gnu/gcc-bin/3.3/include JAVACFLAGS="-C" JAVA_HOME="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3" JAR=gcj-jar JAVAC=gcj emerge -O db avoiding 180Mb download.... So, in the ebuild for db-4 it's not necessary any JDK or JRE. There's another bugs that hurt me: java-config does not recognize gcc as a complete jdk/jre. gij, gcj and gcj-jar are equivalent to any javac, java, jar command. Free to use your preferred compiler :-) -- Sandro
I see this as a java-config bug. At the moment that gcc provides a functional equivalent to any other jdk, there should be no problem to use it. Currently however using gcj is not straightforward at all and environment variables need to be used. Further the gcj class library is not up to specs with respect to an official jdk. Also native bindings might not work as expected. The solution would be to have gcc or a separate ebuild provide a set of scripts that wrap the gcj binaries into the names used by other jdk's. At that point it would be possible to set java to gcj in java-config and have db's java support be build by gcj. Note however that this will probably be an unsupported setup until gcj's library will be more or less equivalent to sun's.
The change is in the package, so closing the bug
