Bug 171843

Er, no, /usr/bin/rebuild-gcj-db showed up in hsqldb-1.80.1-1jpp_1fc,
in a postuninstall script in particular, but I lost it on a busy screen.

All the dependencies are there:

  $ grep java-gcj-compat work/os/pkgs/hsqldb/devel/hsqldb.spec
  BuildRequires:    java-gcj-compat-devel >= 1.0.31
  Requires(post):   java-gcj-compat >= 1.0.31
  Requires(postun): java-gcj-compat >= 1.0.31

What do the following two commands say on your box?

  rpm -q --whatprovides java-gcj-compat
  ls -l /usr/bin/rebuild-gcj-db

$ rpm -q --whatprovides java-gcj-compat
java-1.4.2-gcj-compat-1.4.2.0-40jpp_51rh

and /usr/bin/rebuild-gcj-db does not exist

A direct reason for that seems to be that if I am trying to execute a %post
script for java-1.4.2-gcj-compat-1.4.2.0-40jpp_51rh I am seeing

link /opt/java/jvm-exports/jre incorrect for slave jre_exports
(/usr/lib/jvm-exports/jre jre_exports)

although that script does not bail out and does whatever it does.  In turn
that is caused by that detail that a year ago using jpackage I installed
java-1.5.0-sun in /opt which should be out of way.  Alternatives system
seems to be awfully fragile.

Ok, it looks like the alternative symlinks didn't get made.  I dimly remember
noticing this on my own machine, but was deeply involved in something else so I
just manually created the links intending to report the problem later.  Then I
forgot ;)

Until this gets fixed try this:

 ln -s /usr/lib/jvm/jre-1.4.2-gcj/bin/rebuild-gcj-db /etc/alternatives
 ln -s /etc/alternatives/rebuild-gcj-db /usr/bin

After that you should be able to uninstall your old hsqldb like so:

 rpm -e hsqldb-1.80.1-1jpp_1fc

Xref:
https://www.redhat.com/archives/fedora-devel-java-list/2005-September/thread.html#00078

Even if I remove any traces of /opt/java and try to reinstall things
then I see the same "link /opt/java/jvm-exports/jre incorrect for slave jre_exports"
without any further explanations.  What is more that link may be "incorrect"
but actually it never existed and still is not there.  The message comes
from update-alternatives.

Yes, I know how to "fix" all of that manually but this is not the point.

I was merely trying to make sure you weren't left with a broken box.

To fix that particular "broken box", it turns out, one needs to ensure that files
in /var/lib/alternatives/ do not mention anything in /opt/java/ tree.  After
that it is possible to rerun corresponding /usr/sbin/alternatives calls and links
are becoming as expected.`

I ran into a similar issue where /usr/bin/aot-compile-rpm was missing 
on an FC4+rawhide box, so I took a closer look at this. 
 
In FC4, /usr/bin/aot-compile-rpm is a regular file: 
 
| $ ls -l /usr/bin/aot-compile-rpm 
| -rwxr-xr-x  1 root root 8996 Oct 21 11:27 /usr/bin/aot-compile-rpm 
| $ rpm -qf /usr/bin/aot-compile-rpm 
| java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_31rh.FC4.2 
 
In rawhide, /usr/bin/aot-compile-rpm is an alternatives-managed 
symlink that is supposed to be installed by the %post scriptlet of 
java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_51rh. 
 
 
So, if you update FC4's java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_31rh 
to rawhide's java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_51rh, the %post 
scriptlet fails to create the symlink /usr/bin/aot-compile-rpm.  Why? 
Because when the %post scriptlet runs its 
/usr/sbin/update-alternatives command, the file 
/usr/bin/aot-compile-rpm still exists.  This file is owned by the 
previous version of gcj-compat.  The update-alternatives command 
silently fails to create the symlink. 
 
When the uninstall portion of the update transaction runs, it finds 
the original file /usr/bin/aot-compile-rpm intact.  Since this file is 
not listed in the manifest of the rawhide gcj-compat RPM, the 
uninstall phase removes it.  The end result is that, after the update, 
/usr/bin/aot-compile-rpm is gone. 
 
You can kinda replicate this behavior by the following simple test 
case: 
 
| $ cd /var/tmp 
| $ mkdir targets 
| $ touch targets/{master,slave}-alternative 
| $ mkdir symlinks 
| $ touch symlinks/slave-link 
 
We now have the file /var/tmp/symlinks/slave-link that is not a 
symlink -- just a regular file.  (This mirrors the situation with 
/usr/bin/aot-compile-rpm prior to update.)  We're now going to try to 
install two alternatives-managed symlinks: 
 
| $ sudo /usr/sbin/update-alternatives \ 
|   --install /var/tmp/symlinks/master-link \ 
|             test \ 
|             /var/tmp/targets/master-alternative \ 
|             100 \ 
|   --slave /var/tmp/symlinks/slave-link test_slave /var/tmp/targets/slave-alternative 
 
The result is that /var/tmp/symlinks/master-link got created, but 
/var/tmp/symlinks/slave-link remained intact: 
 
| $ ls -l /var/tmp/symlinks/ 
| total 8 
| lrwxrwxrwx  1 root  root  22 Nov  2 16:19 master-link -> /etc/alternatives/test 
| -rw-rw-r--  1 vadim vadim  0 Nov  2 16:17 slave-link 
| $ readlink -f /var/tmp/symlinks/master-link  
| /var/tmp/targets/master-alternative 
 
Both symlinks did get created in /etc/alternatives/: 
 
| $ ls -l /etc/alternatives/test* 
| lrwxrwxrwx  1 root root 35 Nov  2 16:19 /etc/alternatives/test -> /var/tmp/targets/master-alternative 
| lrwxrwxrwx  1 root root 34 Nov  2 16:19 /etc/alternatives/test_slave -> /var/tmp/targets/slave-alternative 
 

Created attachment 120665 [details]
gcj-compat.run_cmd.patch

To better understand what's going on when you upgrade FC4's
java-1.4.2-gcj-compat-devel to the rawhide version, I rebuilt rawhide's
version with the attached patch.

Created attachment 120666 [details]
java-1.4.2-gcj-compat-2005-11-02.log

When you install the rawhide java-1.4.2-gcj-compat-devel RPM
instrumented with the above patch (attachment #120665 [details] from comment
#13), it logs its scriptlet activity to
/tmp/java-1.4.2-gcj-compat-2005-11-02.log.  The relevant excerpt from
this file is the following:

| post devel
| 16:05:42: ls -l /usr/bin/aot-compile-rpm
| -rwxr-xr-x  1 root root 8994 Oct 21 11:27 /usr/bin/aot-compile-rpm
| 16:05:42: ls -l /usr/lib/jvm/java-1.4.2-gcj/bin/aot-compile-rpm
| -rwxr-xr-x  1 root root 15512 Nov  2 15:58
/usr/lib/jvm/java-1.4.2-gcj/bin/aot-compile-rpm
| 16:05:42: ls -l /etc/alternatives/aot-compile-rpm
| ls: /etc/alternatives/aot-compile-rpm: No such file or directory
| 16:05:42: update-alternatives \
|   --install /usr/bin/javac javac /usr/lib/jvm/java-1.4.2-gcj/bin/javac 1420 \

|   --slave /usr/lib/jvm/java java_sdk /usr/lib/jvm/java-1.4.2-gcj \
|   --slave /usr/lib/jvm-exports/java java_sdk_exports \
|	    /usr/lib/jvm-exports/java-1.4.2-gcj \
|   --slave /usr/bin/javadoc javadoc /usr/lib/jvm/java-1.4.2-gcj/bin/javadoc \
|   --slave /usr/bin/javah javah /usr/lib/jvm/java-1.4.2-gcj/bin/javah \
|   --slave /usr/bin/jar jar /usr/lib/jvm/java-1.4.2-gcj/bin/jar \
|   --slave /usr/bin/rmic rmic /usr/lib/jvm/java-1.4.2-gcj/bin/rmic \
|   --slave /usr/bin/aot-compile-rpm aot-compile-rpm  \
|	    /usr/lib/jvm/java-1.4.2-gcj/bin/aot-compile-rpm
| 16:05:42: ls -l /usr/bin/aot-compile-rpm
| ls: /usr/bin/aot-compile-rpm: No such file or directory
| 16:05:42: ls -l /usr/lib/jvm/java-1.4.2-gcj/bin/aot-compile-rpm
| -rwxr-xr-x  1 root root 15512 Nov  2 15:58
/usr/lib/jvm/java-1.4.2-gcj/bin/aot-compile-rpm
| 16:05:42: ls -l /etc/alternatives/aot-compile-rpm
| ls: /etc/alternatives/aot-compile-rpm: No such file or directory

This shows that prior to the "post devel" scriptlet,
/usr/bin/aot-compile-rpm exists and is a regular file.	After the
update-alternatives command has run, /usr/bin/aot-compile-rpm no
longer exists, and neither does /etc/alternatives/aot-compile-rpm.

I'm not exactly sure why this behaves differently from the simple test
case described in comment #10, but the end result is the same:
/usr/bin/aot-compile-rpm is not there after the update is complete.

To make the long story short, here's what I think will happen if
java-1.4.2-gcj-compat makes it into FC5 in its present rawhide form.

If you install FC5 from scratch on a clean box, you're fine.  All the
expected symlinks should get created.

If you upgrade FC4 to FC5, your /usr/bin/aot-compile-rpm and
/usr/bin/rebuild-gcj-db are goners.

Ok, so the obvious fix for this are triggers on the uninstallation of
java-1.4.2-gcj-compat and -devel less than 0:1.4.2.0-40jpp_44rh.

However, if Tom moves them into this -scripts subpackage he's been talking about
then the alternatives will go away.

Most of these things shouldn't be alternatives links at all. "rebuild-gcj-db" is
only going to be provided by gcj, not by any other jvm.

I've proposed on fedora-devel-java-list that rebuild-gcj-db be removed and its
functionality moved into gcj-dbtool itself.  Once that's done I'll close this bug.

*** This bug has been marked as a duplicate of 170433 ***