Bug 506332 - depends on java-gcj
depends on java-gcj
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: lucene (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-16 14:03 EDT by Juha Tuomala
Modified: 2009-06-17 10:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-16 15:25:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Juha Tuomala 2009-06-16 14:03:05 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.

http://svn.apache.org/repos/asf/lucene/java/trunk/BUILD.txt
-------------------------------------------------------------------
Basic steps:
  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
/bin/sh
/bin/sh
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 = 1.5.0.0-23.fc10
java = 1.5.0
java-1.4.2-gcj-compat > 1.4.2.0-40jpp.111
java-1.5.0 = 1.5.0.0-23.fc10
java-gcj = 1.5.0.0-23.fc10
java-gcj-compat = 1.0.79
java-sasl = 1.5.0.0-23.fc10
jaxp_parser_impl = 1.5.0.0-23.fc10
jce = 1.5.0.0-23.fc10
jdbc-stdext = 1.5.0.0-23.fc10
jdbc-stdext = 3.0
jndi = 1.5.0.0-23.fc10
jndi-cos = 1.5.0.0-23.fc10
jndi-dns = 1.5.0.0-23.fc10
jndi-ldap = 1.5.0.0-23.fc10
jndi-rmi = 1.5.0.0-23.fc10
jre = 1.5.0
jre-1.5.0 = 1.5.0.0-23.fc10
jre-1.5.0-gcj = 1.5.0.0-23.fc10
jre-gcj = 1.5.0.0-23.fc10
jsse = 1.5.0.0-23.fc10
java-1.5.0-gcj = 1.5.0.0-23.fc10
java-1.5.0-gcj(x86-64) = 1.5.0.0-23.fc10

$ rpm -q --provides java-1.6.0-openjdk|grep ^j
jaas = 1:1.6.0.0                                                   
java = 1:1.6.0                                                     
java-1.6.0 = 1:1.6.0.0-18.b16.fc10                                 
java-1.7.0-icedtea = 0:1.7.0.0-0.999
java-fonts = 1:1.6.0.0
java-openjdk = 1:1.6.0.0-18.b16.fc10
java-sasl = 1:1.6.0.0
jce = 1:1.6.0.0
jdbc-stdext = 3.0
jndi = 1:1.6.0.0
jndi-cos = 1:1.6.0.0
jndi-dns = 1:1.6.0.0
jndi-ldap = 1:1.6.0.0
jndi-rmi = 1:1.6.0.0
jre = 1.6.0
jre-1.6.0 = 1:1.6.0.0-18.b16.fc10
jre-1.6.0-openjdk = 1:1.6.0.0-18.b16.fc10
jre-openjdk = 1:1.6.0.0-18.b16.fc10
jsse = 1:1.6.0.0
java-1.6.0-openjdk = 1:1.6.0.0-18.b16.fc10
java-1.6.0-openjdk(x86-64) = 1:1.6.0.0-18.b16.fc10


Like jre >= 1.5.0

Version-Release number of selected component (if applicable):
lucene-2.3.1-3.4.fc10.x86_64

How reproducible:
always.

Steps to Reproduce:
1. yum install -y java-1.6.0-openjdk
2. yum remove java-1.5.0-gcj
3.
  
Actual results:
It tries to remove openoffice.org-core

Expected results:
Successful removal and working openoffice.

Additional info:
http://lucene.apache.org/java/docs/
http://wiki.services.openoffice.org/wiki/OpenJDK  (green for openjdk)
Comment 1 Deepak Bhole 2009-06-16 15:25:32 EDT
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[1] (from IcedTea). We are working on a better solution that uses IcedTea code + Shark/Zero[2] to replace GCJ. When the decision to remove GCJ is made, the dependency will go away automatically.

1: http://en.wikipedia.org/wiki/Just-in-time_compilation
2: http://today.java.net/pub/a/today/2009/05/21/zero-and-shark-openjdk-port.html
Comment 2 Juha Tuomala 2009-06-17 02:52:21 EDT
(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[1] (from IcedTea). 
> We are working on a better solution that uses IcedTea code + 
> Shark/Zero[2] 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?
Comment 3 Deepak Bhole 2009-06-17 10:10:16 EDT
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..
Comment 4 Caolan McNamara 2009-06-17 10:26:31 EDT
http://qa.openoffice.org/issues/show_bug.cgi?id=83625
'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.

Note You need to log in before you can comment on or make changes to this bug.