Bug 175396

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.

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.

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?

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.