Bug 183938
| Summary: | post script fails on upgrade | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Orion Poplawski <orion> |
| Component: | java-1.4.2-gcj-compat | Assignee: | Thomas Fitzsimmons <fitzsim> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.4.2.0-40jpp_83rh | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-03-04 03:04:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Orion Poplawski
2006-03-03 21:58:22 UTC
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:
/usr/share/javadoc/java/java-1.4.2-gcj-compat-1.4.2.0.
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-1.4.2.0' to
`java-1.4.2-gcj-compat-1.4.2.0': 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.
Looks like we were upgrading from: jpackage-utils-1.6.6-1jpp_2rh.noarch.rpm java-1.4.2-gcj-compat-javadoc-1.4.2.0-40jpp_80rh.i386.rpm $ ls -l /usr/share/javadoc/java total 4 lrwxrwxrwx 1 root root 29 Feb 14 17:31 java-1.4.2-gcj-compat-1.4.2.0 -> java-1.4.2-gcj-compat-1.4.2.0 yum.log: Feb 14 17:31:49 Installed: java-1.4.2-gcj-compat-javadoc.i386 1.4.2.0-40jpp_80rh Interesting: # rpm -qf /usr/share/javadoc/java java-1.4.2-gcj-compat-javadoc-1.4.2.0-40jpp_80rh java-1.4.2-gcj-compat-javadoc-1.4.2.0-40jpp_82rh 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. How can /usr/share/javadoc/java be a symlink and rm -f /usr/share/javadoc/java fail? /usr/share/javadoc/java is a *directory*. 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. Fixed in Rawhide. Closing. |