Description of problem: Anaconda upgrade of RHEL4.6::AS -> RHEL5.2-Server-20080212.0 produces multiple upgrade errors for several gcc packages. The upgrade errors are of two kinds: * First to occur are the errors like following: ... Error(s) installing: libstdc++-devel 4.1.2 39.el5 i386 error: unpacking of archive failed on file /usr/lib/gcc/i386-redhat-linux/4.1.2: cpio: rename ... * After libgcj gets upgraded: ... Error(s) installing: libgcj 4.1.2 39.el5 i386 error: unpacking of archive failed on file /usr/lib/gcj-4.1.2: cpio: rename ... Couple of other package upgrades produce following error: ... gij: error while loading shared libraries: libgij.so.7rh: cannot open shared object file: No such file or directory ... Version-Release number of selected component (if applicable): gcc-4.1.2-39.el5 / RHEL5.2-Server-20080212.0
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 432931 has been marked as a duplicate of this bug. ***
Something changed in RHEL4 or RHEL5 that regressed the major release upgrade test result. This failure was not observed when upgrading from RHEL-4/U5 -> RHEL-5/U1. Retesting RHEL-4/U5 -> RHEL-5/U2 upgrades in KATE now. Will post back with results. This should help narrow down what introduces this change in behavior (a RHEL4 change or RHEL5 change). May also test RHEL-4/U6 -> RHEL-5/U1 upgrades. The combination should narrow down the guilty party.
Looking at early test results of upgrades from RHEL-4/U5 -> RHEL-5/U2 this does not appear to happen. This must mean a change was introduced in RHEL-4/U6 that is causing this issue on upgrade?
You're pretty much screwed; you just can't replace directories with symlinks. %pre/%prein will cause problems if the old paths will still be valid after you install the symlinks.
*** Bug 432934 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Argh, just tried to upgrade RHEL5.2 beta gcc-4.1.2-39.el5 to this scratch > gcc-4.1.2-39.el5.1 on ibm-defiant.rhts.boston.redhat.com and the results are > very weird. I thought the only thing rpm doesn't handle is replacement of a > directory with a symlink, but it seems it can't cope even with the opposite > direction, replacement of a symlink (symlink to directory) with a directory. The problem is that file dispositions are calculated before any filesystem changes are done. If the old package has a: /usr/lib/1.2.3/foo file that isn't in the new package set, it will be removed. If, as a result of the new package set, /usr/lib/1.2.3/foo points to some other file in the new package set (due to some components of that path being newly created symlinks), it doesn't matter - it will still get removed.
(In reply to comment #19) > Argh, just tried to upgrade RHEL5.2 beta gcc-4.1.2-39.el5 to this scratch > gcc-4.1.2-39.el5.1 on ibm-defiant.rhts.boston.redhat.com and the results are > very weird. I thought the only thing rpm doesn't handle is replacement of a > directory with a symlink, but it seems it can't cope even with the opposite > direction, replacement of a symlink (symlink to directory) with a directory. Oh, sorry. Directory symlinks are followed, not replaced. (For example, imagine if /usr/local was a symlink to /opt... you want to follow the symlink, not replace it with a dir.)
This is impossible to fix in RHEL5 gcc. Closing this as CANTFIX. If RHEL4 -> RHEL5 upgrades must be supported, we need to errata RHEL4 gcc4 (need a separate bug for that I guess).
thanks James; adding to RHEL5.2 release notes under "Installation-Related Notes" (since this is CLOSED/CANTFIX, i assume this issue will still be present come RHEL5.2 GA?): <quote> When upgrading to Red Hat Enterprise Linux 5.2 from Red Hat Enterprise Linux 4.6, gcc4 may cause the upgrade to fail. As such, you should manually remove the gcc4 package before upgrading. </quote> please advise if any further revisions are required. thanks!
Looks great Don, thanks!
It is actually: <quote> When upgrading to Red Hat Enterprise Linux 5.1 or newer from Red Hat Enterprise Linux 4.6, gcc4 may cause the upgrade to fail. As such, you should manually remove the gcc4 package before upgrading. </quote>
thanks Jakub, corrected in source.
Hi, the RHEL5.2 release notes will be dropped to translation on April 15, 2008, at which point no further additions or revisions will be entertained. a mockup of the RHEL5.2 release notes can be viewed at the following link: http://intranet.corp.redhat.com/ic/intranet/RHEL5u2relnotesmockup.html please use the aforementioned link to verify if your bugzilla is already in the release notes (if it needs to be). each item in the release notes contains a link to its original bug; as such, you can search through the release notes by bug number. Cheers, Don
Tracking this bug for the Red Hat Enterprise Linux 5.3 Release Notes.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team.