From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070325 Firefox/2.0.0.3 Description of problem: I noticed that this package is failing to update as of tcl-8.4.13-15.fc7.i386.rpm Version-Release number of selected component (if applicable): tcl-8.4.13-16.fc7.i386.rpm How reproducible: Always Steps to Reproduce: after a full update an error message is seen update repeated and output captured Actual Results: [root@bentledr-xeon ~]# yum update Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package tcl.i386 1:8.4.13-16.fc7 set to be updated Checking deps for tcl.i386 1-8.4.13-16.fc7 - u Checking deps for tcl.i386 1-8.4.13-14.fc7 - None Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: tcl i386 1:8.4.13-16.fc7 development 1.8 M Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 1.8 M Is this ok [y/N]: y Downloading Packages: (1/1): tcl-8.4.13-16.fc7. 100% |=========================| 1.8 MB 00:19 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : tcl ######################### [1/2] error: unpacking of archive failed on file /usr/lib/tcl8.4: cpio: rename Updated: tcl.i386 1:8.4.13-16.fc7 Complete! [root@bentledr-xeon ~]# Expected Results: a normal update. Additional info: The last update that completed OK was tcl.i386 1:8.4.13-14.fc7.i386
Had a look to see why things are failing and it seems that the failure is as the result of a folder called tcl8.4 existing when the updates are trying to create a symbolic link called tcl8.4 which points at /usr/share/tcl8.4 Anyway remayved the folder named tcl8.4 and all of the wierdly named links to it and did anoter yum update and thistime it completed without errors but the folder now linked to as tcl8.4 in /usr/share was empty so for now I have forced an install of tcl-8.4.13-14 (rpm -i --force) and removed tcl-8.4.13-16.fc7 (rpm -e) Thi leaves tcl-8.4.13-14.fc7 installed with a symbolic link in /usr/lib of tcl8.4 pointing to /usr/share/tcl8.4 which is not empty I will check the latest package with file roller to see if the update should be populating /usr/share/tcl8.4 before trying another update.
The current package tcl-8.4.13-16 contains /usr/share/tcl8.4 fully populated and now updated OK with yum. So I am guessing that there was a change in this package between f7test3 and the first update tcl-8.4.13-14 that cause the observed behavior. so for now the fix to enable tcl to update is probably to just remove the folder tcl8.4 and all the symbolic links to it from /usr/lib before going through the process described in comment #1 before doing yum update tcl
Just checked what was in the package from the original fc7tes3 dvd and that package tcl-8.4.13-13 is OK so I can't explain where the folder in usr/lib named tcl8.4 came from other than it may have been caused by a previous version of yum.
All OK now but I will leave this open for a while for info in case anyone else has had the same problem.
*** Bug 235907 has been marked as a duplicate of this bug. ***
I'm reopening this. This is really a bug in how rpm handles directories to symlinks or vice versa, but we need to work around it in this package for now. I'm marking it as a blocker for F7.
I'm reassining it as rpm problem.
This is known rpm behaviour - don't try and switch between dirs and symlinks.
Fix in tcl-8.4.13-17.fc7