This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 171843 - Alternatives symlinks don't get created
Alternatives symlinks don't get created
Status: CLOSED DUPLICATE of bug 170433
Product: Fedora
Classification: Fedora
Component: hsqldb (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-26 18:41 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-10 16:27:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
gcj-compat.run_cmd.patch (8.73 KB, patch)
2005-11-02 17:12 EST, Vadim Nasardinov
no flags Details | Diff
java-1.4.2-gcj-compat-2005-11-02.log (4.77 KB, text/plain)
2005-11-02 17:20 EST, Vadim Nasardinov
no flags Details

  None (edit)
Description Michal Jaegermann 2005-10-26 18:41:24 EDT
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
Comment 1 Michal Jaegermann 2005-10-26 18:46:23 EDT
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.
Comment 2 Gary Benson 2005-10-27 04:46:26 EDT
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
Comment 3 Michal Jaegermann 2005-10-27 12:10:01 EDT
$ 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.
Comment 4 Gary Benson 2005-10-27 13:04:51 EDT
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
Comment 6 Michal Jaegermann 2005-10-27 13:20:49 EDT
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.
Comment 7 Michal Jaegermann 2005-10-27 13:34:34 EDT
Yes, I know how to "fix" all of that manually but this is not the point.
Comment 8 Gary Benson 2005-10-28 04:36:26 EDT
I was merely trying to make sure you weren't left with a broken box.
Comment 9 Michal Jaegermann 2005-10-28 10:59:29 EDT
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.`
Comment 10 Vadim Nasardinov 2005-11-02 17:07:11 EST
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 
 
Comment 11 Vadim Nasardinov 2005-11-02 17:12:01 EST
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.
Comment 12 Vadim Nasardinov 2005-11-02 17:20:45 EST
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.
Comment 13 Vadim Nasardinov 2005-11-02 17:25:05 EST
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.
Comment 14 Gary Benson 2005-11-03 05:04:42 EST
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.
Comment 15 Bill Crawford 2005-11-06 23:36:57 EST
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.
Comment 16 Thomas Fitzsimmons 2005-11-09 17:09:22 EST
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.
Comment 17 Thomas Fitzsimmons 2005-11-10 16:27:39 EST

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

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