Description of problem:
A number of packages (e.g. eclipse and its subpackages) rely on the presence of
Unfortunately if I have selected the Sun jre as my default via alternatives,
this fails, and lots of packages end up reporting errors during
Version-Release number of selected component (if applicable):
Install this package. Select Sun jre/jvm via alternatives. Upgrade or install
any other package which depends on /usr/bin/rebuild-gcj-db being available.
Error messages during yum update.
This simply shouldn't be accessed via alternatives, at least not for those
packages that need it available by default. Perhaps there could be a symlink
provided somewhere either by the java-blah-gcj-compat package itself, or via a
different mechanism (or, make that command not be a slave, but an alternative in
its own right; that seems like overkill, though, just providing it directly
should be enough).
This also means it is very difficult to have e.g. different versions of the gcj
jvm installed, among other things. Plus, what if other jvm packages need some
kind of database like this? Perhaps an /etc/jvm/rebuild-db.d/ needs to be added?
I can confirm this as well.
rebuild-gcj-db doesn't seem to belong in the java-gcj-compat package. Is there
any reason not to move it into the libgcj package?
We could do that. However, I'm also going to create a java-gcj-compat-scripts
package that sits above jpackage-utils and below java-gcj-compat. It would
contain these miscellaneous gcj-specific scripts, such as rebuild-gcj-db,
rebuild-security-providers and aot-compile-rpm. I think rebuild-gcj-db would
fit in fine there, and having it there rather than in libgcj would give us more
flexibility to experiment with it. I think once we get the functionality that
we want we should build it directly into gcj-dbtool itself.
*** Bug 171843 has been marked as a duplicate of this bug. ***
*** Bug 169218 has been marked as a duplicate of this bug. ***
Fixed in Rawhide, java-1.4.2-gcj-compat-188.8.131.52-40jpp_52rh.