From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Description of problem: # yum update Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package xulrunner.i386 0:1.9-0.beta3.21.nightly20080214.fc9 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: xulrunner i386 1.9-0.beta3.21.nightly20080214.fc9 development 9.5 M Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 9.5 M Is this ok [y/N]: y Downloading Packages: (1/1): xulrunner-1.9-0.be 100% |=========================| 9.5 MB 00:03 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : xulrunner ######################### [1/2] Error unpacking rpm package xulrunner-1.9-0.beta3.21.nightly20080214.fc9.i386 error: unpacking of archive failed on file /usr/lib/xulrunner-1.9pre/dictionaries: cpio: rename Updated: xulrunner.i386 0:1.9-0.beta3.21.nightly20080214.fc9 Complete! Version-Release number of selected component (if applicable): .i386 0:1.9-0.beta3.21.nightly20080214.fc9 How reproducible: Always Steps to Reproduce: 1. yum update Actual Results: Expected Results: Additional info:
This is due to the combination in which the filesystem and rpm are designed and there is no good way to solve the case of a directory containing files to be changed to a symbolic link. The problem is that rpm tries to "replace" files with the new versions and then removes the old files which aren't owned by the new package. So if I were to do something like "rm -rf $libdir/xulrunner/dictionaries" prior to installing the file, rpm would then notice that en_US.aff etc were not owned by the new package and would then unlink (delete) $libdir/xulrunner/dictionaries/en_US.aff. That WOULD follow the symlink and actually delete /usr/share/myspell/en_US.aff which is owned by the hunspell package.... So, this is impossible to fix, actually. The workaround is to remove xulrunner first, and then re-install it. Which sucks, but since this will only be a one-time thing and only affects rawhide, well, it could be worse.
*** Bug 433108 has been marked as a duplicate of this bug. ***
*** Bug 433211 has been marked as a duplicate of this bug. ***
*** Bug 433231 has been marked as a duplicate of this bug. ***
*** Bug 433260 has been marked as a duplicate of this bug. ***
*** Bug 433375 has been marked as a duplicate of this bug. ***
*** Bug 433376 has been marked as a duplicate of this bug. ***
> So if I were to do something like "rm -rf $libdir/xulrunner/dictionaries" > prior to installing the file That would be clearly bad for reasons noted in a comment #1. OTOH [ ! -h $libdir/xulrunner/dictionaries ] && \ rm -rf $libdir/xulrunner/dictionaries would delete this only if that would be a "true" directory and not a symbolic link and a subsequent unpacking by cpio would not have any issues. A number of duplicates shows that this is a rather popular gotcha. It sounds like rm -f "$libdir/xulrunner/dictionaries;"* "cleanup" step also could be of help on many systems.
Your solution doesn't solve the problem in a way that leaves the hunspell package intact.
> Your solution doesn't solve the problem ... Eh? We do not remove anything if .../xulrunner/dictionaries is a link. Possibly I am not aware of all possible hunspell configurations but I did precisely those operations "by hand" to get an update of xulrunner installed.
*** Bug 433612 has been marked as a duplicate of this bug. ***
*WE* don't but rpm *WILL* when it does the upgrade. The old version's file list contained: /usr/lib64/xulrunner/dictionaries /usr/lib64/xulrunner/dictionaries/en-US.aff /usr/lib64/xulrunner/dictionaries/en-US.dic The new version's file list contains: /usr/lib64/xulrunner/dictionaries So rpm will then go and manually delete /usr/lib64/xulrunner/dictionaries/en-US.aff /usr/lib64/xulrunner/dictionaries/en-US.dic And guess what? /usr/lib64/xulrunner/dictionaries -> /usr/share/myspell means that it will really be deleting /usr/share/myspell/en-US.aff and /usr/share/myspell/en-US.dic As far as I know there isn't any way to solve this problem, really. But copying the rpm maintainer in case he knows of a way to do so.
> And guess what? /usr/lib64/xulrunner/dictionaries -> /usr/share/myspell means > that it will really be deleting /usr/share/myspell/en-US.aff and > /usr/share/myspell/en-US.dic Sigh! Maybe a small experiment. OK? In a throwaway directory do 'mkdir dictionaries.gone' and as many times as you want run the following script: #!/bin/sh mkdir -p keep/dictionaries touch keep/dictionaries/en-US.{aff,dic} [ -e dictionaries ] || ln -s keep/dictionaries . mkdir -p dictionaries.gone [ ! -h dictionaries ] && rm -rf dictionaries [ ! -h dictionaries.gone ] && rm -rf dictionaries.gone So what are results?
RPM Lesson time :) An RPM upgrade transaction consists of the following: 1 %pretrans of new package 2 %pre of new package 3 (package install) 4 %post of new package 5 %preun of old package 6 (removal of old package) 7 %postun of old package 8 %posttrans of new package You are suggesting that I add your code in step 2 (%pre). We run your code, and poof, there is no dictionaries/ dir. All good so far! Then all the files from the new package are installed (step 3) and the symlink is created. With your fix, we avoid the cpio error here, which also is good. The next few scriptlets then run, and we get to step 6, which is the uninstallation part. It is also the part I have no control over. RPM looks at the file lists of the old package and the new package. RPM unlinks anything in the file list that the old package contained that the new package doesn't. In this case, /usr/lib64/xulrunner/dictionaries/en-US.aff and /usr/lib64/xulrunner/dictionaries/en-US.dic which currently are owned by hunspell because the link was created.
> RPM Lesson time :) Fine. It is always nice to learn something new. > With your fix, we avoid the cpio error here, which also is good. That was the idea. > RPM unlinks anything in the file list that the old package contained > that the new package doesn't. You may be right to be paranoid here, as rpm bugs are numerous, but AFAIK rpm it is not supposed to unlink things which are still "owned"; possibly by some other package. In this particular case by 'hunspell-en'. As I said before - in principle I did precisely what I suggested in a code, but "manually", in order for an update to proceed (i.e. I removed 'dictionaries' subdirectory in /usr/lib64/xulrunner-1.9pre, and a botched link produced by a failed upgrade, and "updated" xulrunner again). Surprise! /usr/share/myspell/en_US.{aff,dic} still exist and they were installed on "Sat 09 Feb 2008 02:02:25 PM MST". Also 'rpm -Vf /usr/share/myspell/en_US.aff' does not have any complaints. xulrunner, now at 1.9-0.beta3.23.nightly20080217.fc9, also looks quite healthy. OTOH I cannot tell now if I did "rpm -Fvh xulrunner*.rpm" or let yum to handle that.
The trick to replace directory with a symlink is to do it in %pretrans, regular %pre is too late in the process.
*** Bug 434646 has been marked as a duplicate of this bug. ***
*** Bug 434784 has been marked as a duplicate of this bug. ***
I was able to install the latest update after removing the old version with --nodeps and then installing the latest RPM from Koji. Thanks!
Talked more with panu about doing this in %pretrans and it looks like it will end up being more pain then it's worth, so going to hold firm at leaving this alone. Sucks that some people got bit by it, but there's an easy workaround (rpm -e --nodeps the old package and install the new one) and it won't affect anyone doing F8->F9 upgrades. It only affects people running rawhide with an earlier version of xulrunner. Additionally, this will go away at some point even for rawhide users who got bit by it when the xulrunner directory changes for the XR 1.9 final release. <Panu> caillon: %pretrans happens before fingerprinting, %pre afterwards <caillon> Panu, fingerprinting overrides the file list? <Panu> caillon: the gotcha with %pretrans is that on initial install it happens in a total void - there's absolutely nothing in the install root at that point <caillon> so i want to remove the %pretrans for F9 final when people will be installing it for the first time? or even the beta coming up? <Panu> so you'll actually need to do the above with the embedded lua, not shell script (because there's no shell at that point) <caillon> (since xulrunner was not in F8) <caillon> oooh <caillon> fun <Panu> caillon: yeah.. although dunno if messing with it is actually worth the trouble at all since it doesn't affect real upgrades <caillon> and Requires(pretrans): /bin/sh wouldnt work? <Panu> caillon: no, it wouldn't, because %pretrans runs before a single file has been laid out <Panu> ie the transaction hasn't even really started yet, hence %pretrans :)
*** Bug 436050 has been marked as a duplicate of this bug. ***
*** Bug 436150 has been marked as a duplicate of this bug. ***
*** Bug 436217 has been marked as a duplicate of this bug. ***
*** Bug 435565 has been marked as a duplicate of this bug. ***
*** Bug 437311 has been marked as a duplicate of this bug. ***
*** Bug 437472 has been marked as a duplicate of this bug. ***
*** Bug 437438 has been marked as a duplicate of this bug. ***
Doing a 'rpm -e --nodeps xulrunner' doesn't remove the directory /usr/lib64/xulrunner-1.9pre. And if try to reinstall it, the same error will be given. Manually removing the directory and install xulrunner again will solve the problem. I don't know if this is the best practice, but it does the job.
*** Bug 437480 has been marked as a duplicate of this bug. ***
*** Bug 437610 has been marked as a duplicate of this bug. ***
*** Bug 438636 has been marked as a duplicate of this bug. ***
*** Bug 438948 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > Doing a 'rpm -e --nodeps xulrunner' doesn't remove the directory /usr/lib64/xulrunner-1.9pre. > > And if try to reinstall it, the same error will be given. > > Manually removing the directory and install xulrunner again will solve the problem. > > I don't know if this is the best practice, but it does the job. That's how I fixed it. It's only an alpha release, so if it gets borked, I'd just re-install. Obviously not a good approach for a finished product, but it works in the interim.
*** Bug 440522 has been marked as a duplicate of this bug. ***
*** Bug 441624 has been marked as a duplicate of this bug. ***