Description of problem: Updating : hsqldb ##################### [ 72/174] /var/tmp/rpm-tmp.15150: line 7: /usr/bin/rebuild-gcj-db: No such file or directory error: %post(hsqldb-1.80.1-1jpp_3fc.x86_64) scriptlet failed, exit status 127 and now 'rpm -q hsqldb' shows both hsqldb-1.80.1-1jpp_1fc hsqldb-1.80.1-1jpp_3fc An invocation of /usr/bin/rebuild-gcj-db was absent from the previous version. If this is optional then it should be [ -x /usr/bin/rebuild-gcj-db ] && /usr/bin/rebuild-gcj-db If this is really required then a dependency is missing. hsqldb itself is really installed because openoffice.org-core pulled that in. Version-Release number of selected component (if applicable): hsqldb-1.80.1-1jpp_3fc
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 ***