Bug 433096 - (xulrunner-cpio) xulrunner failes to rename file during unpacking
xulrunner failes to rename file during unpacking
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: xulrunner (Show other bugs)
rawhide
i386 Linux
low Severity low
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
:
: 433108 433211 433231 433260 433375 433612 434646 434784 435565 436050 436150 436217 437311 437438 437472 437480 437610 438636 438948 441624 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-16 03:29 EST by Mitko Rürup
Modified: 2008-04-09 01:06 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-16 12:14:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mitko Rürup 2008-02-16 03:29:28 EST
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:
Comment 1 Christopher Aillon 2008-02-16 12:14:26 EST
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.
Comment 2 Christopher Aillon 2008-02-16 12:15:02 EST
*** Bug 433108 has been marked as a duplicate of this bug. ***
Comment 3 Matěj Cepl 2008-02-17 12:32:55 EST
*** Bug 433211 has been marked as a duplicate of this bug. ***
Comment 4 Matěj Cepl 2008-02-17 17:31:44 EST
*** Bug 433231 has been marked as a duplicate of this bug. ***
Comment 5 Matěj Cepl 2008-02-18 06:19:37 EST
*** Bug 433260 has been marked as a duplicate of this bug. ***
Comment 6 Matěj Cepl 2008-02-18 17:41:19 EST
*** Bug 433375 has been marked as a duplicate of this bug. ***
Comment 7 Matěj Cepl 2008-02-18 17:45:28 EST
*** Bug 433376 has been marked as a duplicate of this bug. ***
Comment 8 Michal Jaegermann 2008-02-18 19:37:10 EST
> 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.
Comment 9 Christopher Aillon 2008-02-19 16:09:48 EST
Your solution doesn't solve the problem in a way that leaves the hunspell
package intact.
Comment 10 Michal Jaegermann 2008-02-19 17:30:21 EST
> 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.
Comment 11 Christopher Aillon 2008-02-20 16:21:09 EST
*** Bug 433612 has been marked as a duplicate of this bug. ***
Comment 12 Christopher Aillon 2008-02-20 16:30:28 EST
*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.
Comment 13 Michal Jaegermann 2008-02-20 18:45:32 EST
> 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?
Comment 14 Christopher Aillon 2008-02-20 23:11:04 EST
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.

Comment 15 Michal Jaegermann 2008-02-21 00:27:10 EST
> 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.
Comment 16 Panu Matilainen 2008-02-21 02:28:45 EST
The trick to replace directory with a symlink is to do it in %pretrans, regular
%pre is too late in the process.
Comment 17 Christopher Aillon 2008-02-24 16:59:36 EST
*** Bug 434646 has been marked as a duplicate of this bug. ***
Comment 18 Matěj Cepl 2008-02-25 12:42:44 EST
*** Bug 434784 has been marked as a duplicate of this bug. ***
Comment 19 Gideon Mayhak 2008-02-25 21:34:08 EST
I was able to install the latest update after removing the old version with
--nodeps and then installing the latest RPM from Koji.  Thanks!
Comment 20 Christopher Aillon 2008-02-27 02:45:37 EST
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 :)
Comment 21 Matěj Cepl 2008-03-05 05:10:27 EST
*** Bug 436050 has been marked as a duplicate of this bug. ***
Comment 22 Christopher Aillon 2008-03-05 13:09:04 EST
*** Bug 436150 has been marked as a duplicate of this bug. ***
Comment 23 Matěj Cepl 2008-03-05 17:42:06 EST
*** Bug 436217 has been marked as a duplicate of this bug. ***
Comment 24 Flóki Pálsson 2008-03-08 06:25:19 EST
*** Bug 435565 has been marked as a duplicate of this bug. ***
Comment 25 Matěj Cepl 2008-03-13 11:25:00 EDT
*** Bug 437311 has been marked as a duplicate of this bug. ***
Comment 26 Matěj Cepl 2008-03-14 11:49:15 EDT
*** Bug 437472 has been marked as a duplicate of this bug. ***
Comment 27 Matěj Cepl 2008-03-14 12:05:21 EDT
*** Bug 437438 has been marked as a duplicate of this bug. ***
Comment 28 José Tiburcio Ribeiro Netto 2008-03-14 14:51:54 EDT
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.
Comment 29 Will Woods 2008-03-14 15:04:36 EDT
*** Bug 437480 has been marked as a duplicate of this bug. ***
Comment 30 Christopher Aillon 2008-03-17 14:19:59 EDT
*** Bug 437610 has been marked as a duplicate of this bug. ***
Comment 31 Ignacio Vazquez-Abrams 2008-03-23 13:27:57 EDT
*** Bug 438636 has been marked as a duplicate of this bug. ***
Comment 32 Matěj Cepl 2008-03-26 09:47:49 EDT
*** Bug 438948 has been marked as a duplicate of this bug. ***
Comment 33 Austin 2008-03-26 20:48:21 EDT
(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.
Comment 34 Matěj Cepl 2008-04-04 01:13:03 EDT
*** Bug 440522 has been marked as a duplicate of this bug. ***
Comment 35 Ignacio Vazquez-Abrams 2008-04-09 01:06:31 EDT
*** Bug 441624 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.