Red Hat Bugzilla – Bug 506332
depends on java-gcj
Last modified: 2009-06-17 10:26:31 EDT
Description of problem:
After installing the openjdk java (IcedTea) and trying to remove
java-gcj, it ends up removing openoffice. Based on the fact that
IcedTea is coming from Sun Microsystems, it's reasonable to claim
that it's more 'the java' than any other implementation.
0) Install JDK 1.4 (or greater), Ant 1.6.3 (or greater)
1) Download Lucene from Apache and unpack it
2) Connect to the top-level of your Lucene installation
3) Install JavaCC (optional)
4) Run ant
We'll assume that you know how to get and set up the JDK - if you
don't, then we suggest starting at http://java.sun.com and learning
more about Java, before returning to this README. Lucene runs with
JDK 1.4 and later.
Nothing claims that it wouldn't work with openjdk. I suggest that
what now is:
$ rpm -q --requires lucene
java-gcj-compat >= 1.0.43
java-gcj-compat >= 1.0.43
would depend on some common java dependency:
$ rpm -q --provides java-1.5.0-gcj|grep ^j
jaas = 22.214.171.124-23.fc10
java = 1.5.0
java-1.4.2-gcj-compat > 126.96.36.199-40jpp.111
java-1.5.0 = 188.8.131.52-23.fc10
java-gcj = 184.108.40.206-23.fc10
java-gcj-compat = 1.0.79
java-sasl = 220.127.116.11-23.fc10
jaxp_parser_impl = 18.104.22.168-23.fc10
jce = 22.214.171.124-23.fc10
jdbc-stdext = 126.96.36.199-23.fc10
jdbc-stdext = 3.0
jndi = 188.8.131.52-23.fc10
jndi-cos = 184.108.40.206-23.fc10
jndi-dns = 220.127.116.11-23.fc10
jndi-ldap = 18.104.22.168-23.fc10
jndi-rmi = 22.214.171.124-23.fc10
jre = 1.5.0
jre-1.5.0 = 126.96.36.199-23.fc10
jre-1.5.0-gcj = 188.8.131.52-23.fc10
jre-gcj = 184.108.40.206-23.fc10
jsse = 220.127.116.11-23.fc10
java-1.5.0-gcj = 18.104.22.168-23.fc10
java-1.5.0-gcj(x86-64) = 22.214.171.124-23.fc10
$ rpm -q --provides java-1.6.0-openjdk|grep ^j
jaas = 1:126.96.36.199
java = 1:1.6.0
java-1.6.0 = 1:188.8.131.52-18.b16.fc10
java-1.7.0-icedtea = 0:184.108.40.206-0.999
java-fonts = 1:220.127.116.11
java-openjdk = 1:18.104.22.168-18.b16.fc10
java-sasl = 1:22.214.171.124
jce = 1:126.96.36.199
jdbc-stdext = 3.0
jndi = 1:188.8.131.52
jndi-cos = 1:184.108.40.206
jndi-dns = 1:220.127.116.11
jndi-ldap = 1:18.104.22.168
jndi-rmi = 1:22.214.171.124
jre = 1.6.0
jre-1.6.0 = 1:126.96.36.199-18.b16.fc10
jre-1.6.0-openjdk = 1:188.8.131.52-18.b16.fc10
jre-openjdk = 1:184.108.40.206-18.b16.fc10
jsse = 1:220.127.116.11
java-1.6.0-openjdk = 1:18.104.22.168-18.b16.fc10
java-1.6.0-openjdk(x86-64) = 1:22.214.171.124-18.b16.fc10
Like jre >= 1.5.0
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum install -y java-1.6.0-openjdk
2. yum remove java-1.5.0-gcj
It tries to remove openoffice.org-core
Successful removal and working openoffice.
http://wiki.services.openoffice.org/wiki/OpenJDK (green for openjdk)
The dependency on GCJ currently exists because there are ahead-of-time compiled pieces in the lucene rpm. These are needed to ensure reasonable speed on platforms without a JIT (from IcedTea). We are working on a better solution that uses IcedTea code + Shark/Zero to replace GCJ. When the decision to remove GCJ is made, the dependency will go away automatically.
(In reply to comment #1)
> The dependency on GCJ currently exists because there are
> ahead-of-time compiled pieces in the lucene rpm. These are needed to
> ensure reasonable speed on platforms without a JIT (from IcedTea).
> We are working on a better solution that uses IcedTea code +
> Shark/Zero to replace GCJ. When the decision to
> remove GCJ is made, the dependency will go away automatically.
Thank you for clarification, this gives the clear picture about the situation.
Unfortunately the whole proved to be even more bloated than I expected,
all that (shark/zero text) going inside wordprocessor is a scary thought.
Why can't they use the C++ implementation of lucene in OOo?
That is certainly a possibility. I am not knowledgeable enough on that front to know all the technical issues though. Adding Caolan to cc. He is the maintainer of the OpenOffice.org packages and can comment..
'lucene4c is dead anyway: "2006-10-15 - Project closed due to lack of activity"'
I fixed the whole help thing at one stage to no longer need Java during the build process back when we were using a C++ help engine and just Java for preprocessing. Then the decision was made to use lucene as the new help engine and Java was put back in for both the preprocessing and runtime. If anyone wants to port OOo's help over the lucene4c that'd be groovy, especially for build time.
But the core of *this* issue is the continuation of aot-compiling with gcj and packaging aot libs by default which forces the java-gcj stack onto all installs when a java package with aot libs in it is intalled. So moving OOo off java lucene won't help that as the same thing would just happen with another java dependency of OOo, or indeed of nearly everything else in Fedora.
Ideally we'd bite the bullet on this and not aot anything any more, or at the least only aot for platforms where the jit is considered too sluggish.