Red Hat Bugzilla – Bug 235812
Update failure tcl-8.4.13-15.fc7.i386.rpm & tcl-8.4.13-16.fc7.i386.rpm
Last modified: 2013-01-09 23:15:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20070325 Firefox/220.127.116.11
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):
Steps to Reproduce:
after a full update an error message is seen
update repeated and output captured
[root@bentledr-xeon ~]# yum update
Setting up Update Process
--> 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
Package Arch Version Repository Size
tcl i386 1:8.4.13-16.fc7 development 1.8 M
Install 0 Package(s)
Update 1 Package(s)
Remove 0 Package(s)
Total download size: 1.8 M
Is this ok [y/N]: y
(1/1): tcl-8.4.13-16.fc7. 100% |=========================| 1.8 MB 00:19
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
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
a normal update.
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