From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050827 Fedora/1.1-0.2.8.deerpark.alpha2 Firefox/1.0+
Description of problem:
/var/tmp/rpm-tmp.27634: line 24: /usr/bin/rebuild-gcj-db: No such file or directory
error: %post(jonas-4.3.3-1jpp_11fc.i386) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.94650: line 1: /usr/bin/rebuild-gcj-db: No such file or directory
error: %post(jonas-examples-4.3.3-1jpp_11fc.i386) scriptlet failed, exit status 127
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Is this with a fres install of the FC-development tree?
fres -> fresh
Did you have any additional java packages installed - particularly those using
alternatives from JPackage.
If you have a different alternative selected /usr/bin/rebuild-gcj-db is not
there which is *not* an RPM bug.
Yes, I use jpackage, with the Sun Javac.
I see rebuild-gcj-db appear when gcj is chosen.
However, I don't see how that's not a bug - sure looks like one to me. I see
scripts failing, duplicate packages being left in the rpm database, and
unnecessary confusion that the end user should not be subjected to.
If the scripts fail on removal, the package is left installed by design.
Gary - if people have switched to a non gcj java package the slave symlink will
not be present. Perhaps the %post packages should use the full path to the
file, or the script should not be controlled by alternatives.
No, rebuild-gcj-db should never have been made an alternative. We need to
create a separate java-gcj-compat-scripts package that java-1.4.2-gcj-compat
depends on and that depends on jpackage-utils. In that package we should put
all these gcj-specific scripts. If no one beats me to it, I'll do this next
week; there are many duplicates filed for this issue.
*** This bug has been marked as a duplicate of 170433 ***