Bug 175396 - Unwanted libgcj dependency when installing openoffice.org
Unwanted libgcj dependency when installing openoffice.org
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-09 14:06 EST by Ron
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-12 05:26:59 EST
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 Ron 2005-12-09 14:06:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Description of problem:
Installing openoffice.org also installs unwanted libgcj.  Libgcj is a counterfeit of real Java(TM) from Sun Microsystems.  It uses the same executable names as the real Java(TM) runtime.  In a production environment which requires the use of an industrial-strength, certified Java(TM) runtime (such as JRockit from BEA or the Java(TM) runtime from Sun Microsystems), the installation of openoffice.org causes libgcj to be installed, which interferes with the operation of the real, certified Java(TM) runtime.  The libgcj and other unnecessary dependent modules can be removed using "rpm -e --nodeps <modulename ...>", and openoffice will continue to operate correctly.

Please remove the unnecessary dependency on libgcj and other counterfeit Java(TM) packages, without disabling Java(TM) functionality in openoffice when openoffice detects that there is a Java(TM) runtime installed.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install openoffice.org
2. Note that it also installs libgcj and other counterfeit Java(TM) packages which are not valid, certified Java(TM) implementations
3. Install a valid, certified Java(TM) runtime.  This will usually go into a directory under /usr/java.
4. Add /usr/java/<java-dir>/bin to the end of the PATH environment variable in /root/.bashrc.  Be sure to export PATH.
5. Log in as root.  Type "which java".  It comes back with "/usr/bin/java".  This is the counterfeit libgcj java executable.
6. Run "rpm -e --nodeps libgcj".
7. Log out and back in as root.  Now type "which java".  It should come back with "/usr/java/<java-dir>/bin/java".  This is the licensed, certified Java(TM) executable.

Additional info:
Comment 1 Caolan McNamara 2005-12-10 06:07:46 EST
ldd /usr/lib/openoffice.org2.0/program/libofficebean.so

libgcj is required to satisfy OOo's link time requirements, officebean is not
commonly used, but it does need to be linked against libgcj. 

OOo requires *a* java(tm) to be present to enable everything to work, e.g.
wizards. Fedora(tm) does not provide sun java(tm), but fedora(tm) does provide
gcj as a java(tm) replacement, so it's perfectly reasonable for fedora(tm) OOo
to require libgcj in order to guarantee that there will a dlopen-able java(tm)
jvm available

More importantly than all this is that "/usr/bin/java" is a link which is
controlled by the alternatives system. e.g. /usr/sbin/alternatives --display java 

So installing a sun java(tm) rpm which is aware of the alternatives system will
set the alternatives to sun java(tm), while still retaining the actual "libgcj"
and "gij" programs. i.e. http://fedora.redhat.com/docs/release-notes/fc4/#id2503931
and in details http://www.fedorafaq.org/#java

Many of the java(tm) using packages in fedora(tm) require libgcj, e.g.
xerces/xml-commons, it's not specific to OOo.
Comment 2 Ron 2005-12-10 16:17:30 EST
Isn't there a difference between link-time requirements and runtime
requirements?  Why can't it be made to use libgcj at build time, but then use
whatever VM is available at runtime?  This seems entirely reasonable.

As a professional Java-on-Linux developer, I can tell you for sure that people
like me comprise a huge chunk of the market.  For us, it just doesn't make sense
to have a fake Java runtime installed by default in FC4, when we didn't ask for
it, and then be forced to jump through hoops just to get rid of it.

I've also seen in other bug reports that after getting rid of libgcj and
installing Sun's VM, yum update sometimes deletes the Sun VM and replaces it
with libgcj without even asking.  To me, as a professional Java developer who
counts on the Sun or BEA VM to be installed and working properly, having libgcj
even appear on my system at all, when I didn't ask for it, is a huge bug.

Also note that the BEA VM, which is used on high-volume and enterprise-level
servers, is not delivered as an RPM, so what I'm hearing from the excuse above,
is that if you want to use the BEA VM and OpenOffice (or pretty much anything
else) on the same machine, you're hosed.

I say we should either get rid of all runtime/install-time dependencies on
libgcj or ditch it completely.  From what I'm seeing, there are lots of people
who agree with me.  It's more of a nuisance than a benefit, because it's not a
certified Java VM.  Besides, the whole point of Java, is that you can pick the
VM that works well for your applcation and platform.

If FC4 restricts which VMs you can use in any way, professional Java-on-Linux
developers (and there are TONS of them) will use a different distro.  This is
not a religious issue, it's purely practical, purely business.
Comment 3 Ron 2005-12-10 16:24:18 EST
Sorry, I forgot to mention another point.

RPM-packaged software (as well as rpm, yum and up2date) must play nicely with
non-RPM-packaged software (such as BEA's Java VM and the tarball versions of
Sun's Java VM).  This is a general principle which I think has been overlooked
in the development of these tools, as well as in development of the various
packages which comprise FC4 and other RPM-based distros.

It's incredibly important to be able to install non-RPM-packaged software on any
distro and not have it hijacked by a competing RPM package which wasn't
requested and isn't wanted.

This is the core of the problem, I believe.  The install-time dependencies
between RPM packages are too tight in some cases, e.g. openoffice.org and libgcj
et. al.  By more loosely coupling these packages (require libgcj-devel or
whatever in order to build openoffice.org but don't require libgcj at runtime,
rather detect at runtime whether a VM is installed and use it if it's there), we
achieve much more flexibility/usability.  This would allow a user who didn't
want libgcj, to simply uninstall it.  Then all software which uses libgcj would
simply detect that it was absent and not use GNU Java functionality.  Then if
the user installs a Java VM, there would be a java executable in the PATH (or a
shared library in the library path) and the affected applications would find it
and use it instead.

Make sense?
Comment 4 Caolan McNamara 2005-12-12 05:26:59 EST
You have to take up such a general issue with on the general fedora java mailing
lists, or with package "java-1.4.2-gcj-compat". RH OOo as built with gcj does
depends on libgcj for link requirements for officebean, not just
build-requirements, so requiring libgcj is correct.

But currently I just don't think there is an specific issue here with relation
to the current FC-4 or rawhide openoffice.org. There is no collision between
having *libgcj* installed and a given java installed. OOo detects at run-time
what jvm is installed and uses it. There isn't a problem in having
/usr/lib/libgcj.so.6 on your system as well as having sun java installed. Your
problems is with package "java-1.4.2-gcj-compat" not with package "libgcj"

e.g. rpm -q --provides java-1.4.2-gcj-compat

this package requires libgcj, and provides "java". That's the glue between
"libgcj" and "java" which causes the problem. libgcj on it's own is just like
"libc". It is "java-1.4.2-gcj-compat" which creates the /usr/bin/java links
using update-alternatives in its %post section which are troubling you. OOo
doesn't directly require "java-1.4.2-gcj-compat". Theres is no more that the OOo
package can do here.

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