Bug 183938 - post script fails on upgrade
post script fails on upgrade
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
Depends On:
  Show dependency treegraph
Reported: 2006-03-03 16:58 EST by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-03 22:04:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2006-03-03 16:58:22 EST
Description of problem:

While upgrading my FC development box:

  Updating  : java-1.4.2-gcj-compat-javado ##################### [ 80/173]
rm: cannot remove `/usr/share/javadoc/java': Is a directory
ln: creating symbolic link
`/usr/share/javadoc/java/java-1.4.2-gcj-compat-' to
`java-1.4.2-gcj-compat-': File exists
error: %post(java-1.4.2-gcj-compat-javadoc- scriptlet
failed, exit status 1
Comment 1 Thomas Fitzsimmons 2006-03-03 17:45:37 EST
What version of jpackage-utils were you updating from? 
jpackage-utils-1.6.6-1jpp_1rh gave up ownership of /usr/share/javadoc/java so
/usr/share/javadoc/java should be removed when it is installed.

All versions of java-1.4.2-gcj-compat-javadoc make /usr/share/javadoc/java a
symlink to the fully-qualified package javadoc dir:

The only reason I can think of that you'd see:

rm: cannot remove `/usr/share/javadoc/java': Is a directory

is because yum is updating java-1.4.2-gcj-compat-javadoc before updating
jpackage-utils.  Do you know which got installed first?

As for:

ln: creating symbolic link
`/usr/share/javadoc/java/java-1.4.2-gcj-compat-' to
`java-1.4.2-gcj-compat-': File exists

should use ln -sf rather than just ln -s.  Here is the current
java-1.4.2-gcj-compat-javadoc %post section:

%post javadoc
rm -f %{_javadocdir}/%{name} %{_javadocdir}/java
ln -s %{name}-%{version} %{_javadocdir}/%{name}
ln -s %{name}-%{version} %{_javadocdir}/java

I should change this to:

%post javadoc
  rm -f %{_javadocdir}/%{name} %{_javadocdir}/java
  ln -sf %{name}-%{version} %{_javadocdir}/%{name}
  ln -sf %{name}-%{version} %{_javadocdir}/java
} || :

The enclosing { } || : will ensure that yum continues even if the %post
scriptlet fails.
Comment 2 Orion Poplawski 2006-03-03 18:08:53 EST
Looks like we were upgrading from:


$ ls -l /usr/share/javadoc/java
total 4
lrwxrwxrwx 1 root root 29 Feb 14 17:31 java-1.4.2-gcj-compat- ->

Feb 14 17:31:49 Installed: java-1.4.2-gcj-compat-javadoc.i386


# rpm -qf /usr/share/javadoc/java

this is from the post failure I believe.

I think the yum upgrade method installs the new package first then removes the
old, so the directory is still there during an upgrade.

Comment 3 Thomas Fitzsimmons 2006-03-03 18:13:09 EST
How can /usr/share/javadoc/java be a symlink and rm -f /usr/share/javadoc/java fail?
Comment 4 Orion Poplawski 2006-03-03 18:23:26 EST
/usr/share/javadoc/java is a *directory*.
Comment 5 Thomas Fitzsimmons 2006-03-03 21:09:15 EST
The previous upgrade to jpackage-utils-1.6.6-1jpp_1rh must have failed.  No
package installs /usr/share/javadoc/java as a directory anymore, though
jpackage-utils < 1.6.6-1jpp_1rh did.

In any case, java-1.4.2-gcj-compat-javadoc should protect against this so I'll
build my proposed fix into Rawhide.
Comment 6 Thomas Fitzsimmons 2006-03-03 22:04:47 EST
Fixed in Rawhide.  Closing.

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