Bug 484240 - error: unpacking of archive failed on file /usr/share/gallery2/lib/smarty: cpio: rename
error: unpacking of archive failed on file /usr/share/gallery2/lib/smarty: cp...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gallery2 (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
:
: 497098 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-05 11:07 EST by Eric Paris
Modified: 2009-05-26 14:47 EDT (History)
10 users (show)

See Also:
Fixed In Version: 2.3-7.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-27 17:40:54 EDT
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 Eric Paris 2009-02-05 11:07:05 EST
ran yum update -y today and everything basically worked except:

  Updating       : gallery2                              52/114 
Error unpacking rpm package gallery2-2.3-3.fc10.noarch
error: unpacking of archive failed on file /usr/share/gallery2/lib/smarty: cpio: rename

So what I'm left with was:

[root@paris-laptop ~]# rpm -q gallery2
gallery2-2.3-1.fc10.noarch
[root@paris-laptop ~]# rpm -q gallery2-httpauth
gallery2-httpauth-2.3-3.fc10.noarch

so gallery2 wasn't updated at all.  running rpm or yum to try to update gallery2 always results in the same problem.  So I tried to remove gallery2 and reinstall.  Naada.

[root@paris-laptop ~]# rpm -e gallery2
error: Failed dependencies:
	gallery2 = 2.3-3.fc10 is needed by (installed) gallery2-httpauth-2.3-3.fc10.noarch
	gallery2 = 2.3-3.fc10 is needed by (installed) gallery2-classic-2.3-3.fc10.noarch
	gallery2 = 2.3-3.fc10 is needed by (installed) gallery2-matrix-2.3-3.fc10.noarch
	gallery2 = 2.3-3.fc10 is needed by (installed) gallery2-tile-2.3-3.fc10.noarch
	gallery2 = 2.3-3.fc10 is needed by (installed) gallery2-dcraw-2.3-3.fc10.noarch

ok, let yum solve the dependancies:
[root@paris-laptop ~]# yum remove -y gallery2
Loaded plugins: refresh-packagekit
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package gallery2.noarch 0:2.3-1.fc10 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================================================================================================================================================
 Package                                          Arch                                           Version                                               Repository                                         Size
===============================================================================================================================================================================================================
Removing:
 gallery2                                         noarch                                         2.3-1.fc10                                            installed                                          18 M

Transaction Summary
===============================================================================================================================================================================================================
Install      0 Package(s)         
Update       0 Package(s)         
Remove       1 Package(s)         

Downloading Packages:
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
gallery2 is needed by (installed) gallery2-httpauth-2.3-3.fc10.noarch
gallery2 is needed by (installed) gallery2-classic-2.3-3.fc10.noarch
gallery2 is needed by (installed) gallery2-matrix-2.3-3.fc10.noarch
gallery2 is needed by (installed) gallery2-tile-2.3-3.fc10.noarch
gallery2 is needed by (installed) gallery2-dcraw-2.3-3.fc10.noarch
Complete!
(1, [u'Please report this error in http://yum.baseurl.org/report'])


Anywy, the real fix is to figure out why cpio failed and rpm left me in this screwed up state.  I'm also asking the yum people to help make yum able to get me out of the this screwed up state.
Comment 1 Eric Paris 2009-02-05 11:07:33 EST
rpm-4.6.0-0.rc3.1.fc10.i386
yum-3.2.21-2.fc10.noarch
Comment 2 Eric Paris 2009-02-05 11:11:30 EST
and why does rpm refuse to remove gallery2 vers 2.3-1 when the dependancy is on version 2.3-3?

There is no dependancy between
gallery2-httpauth-2.3.3 and gallery2-2.3-1
Comment 3 Panu Matilainen 2009-02-05 13:12:21 EST
The cause of the original problem is that gallery2 is trying to replace a directory with a symlink. That just does not work (never has) without some extra hoops, this is a bug in the updated gallery2 package.

The dependency issue is easily reproducable:
# rpm -U A-1.0-1.fc10.noarch.rpm A-subpkg-1.0-1.fc10.noarch.rpm 
# rpm -U --nodeps A-subpkg-2.0-1.fc10.noarch.rpm 
# rpm -e A
error: Failed dependencies:
	A = 2.0-1.fc10 is needed by (installed) A-subpkg-2.0-1.fc10.noarch

It basically ends up thinking removing A here *causes* the unsatisfied dependency as the only thing providing A is going away, but here the dependency was broken already by --nodeps (or in your case, failed upgrade). Mostly the issue is that the reporting is misleading, but yeah it's kind of a bug.

The easiest cure is probably "rpm -e --nodeps gallery2; yum install gallery2", which should also sort out the symlink<->directory issue.
Comment 4 Gwyn Ciesla 2009-02-06 09:44:42 EST
I did this same sort of thing with moodle in August and no one reported problems.  Can you advise me on what sort of hoops you mean?
Comment 5 Jeff Johnson 2009-04-03 12:04:25 EDT
The ususal hoop is to add a %pretrans scriptlet
to create the symlink before file fingerprints
are computed.

What will most definitely __NOT__ work is messing
around with %post et al scriptlets, fingerprints (from
which file resolutions are computed which determine
how the symlink is created or not) are computed long
before any %post et al scriptlet action can be attempted.
Comment 6 Gwyn Ciesla 2009-04-03 12:17:46 EDT
I've never heard of %pretrans.  Is this documented anywhere?  Sounds like a perfect solution.  Does it work the same way as %post and %pre, only before the entire transaction?
Comment 7 Elia Pinto 2009-04-03 12:52:15 EDT
(In reply to comment #6)
> I've never heard of %pretrans.  Is this documented anywhere?  Sounds like a
> perfect solution.  Does it work the same way as %post and %pre, only before the
> entire transaction?  


See comment 12 of this 

https://bugzilla.redhat.com/show_bug.cgi?id=433096
Comment 8 Gwyn Ciesla 2009-04-03 13:00:21 EDT
I see.  So I should essentially:

1. Move my dir/symlink monkey business from %pre to %pretrans
2. Rebuild
3. Push in bodhi
4. Profit!

Agreed?
Comment 9 Jeff Johnson 2009-04-03 13:08:27 EDT
While the action undertaken by rpm in comment #12 may be
surprising, the behavior has nothing to to with whether %pretrans
is useful in other cases. Sure you don't want to go blindly symlinking
paths to content in other packages, any more than you want to
do
    %post
    rm -rf /
or (while using rpmbuild)
    Name: ~;

%pretrans has been in rpm for years. No documentation is largely
political censorship from those who do not believe %pretrans is
adequate to the task. The issue remains highly controversial.

But the mechanism is quite sound.

And you will _NOT_ succeed messing around with %post scriptlets
for the reasons I have stated.

You _MAY_ arrive at some point that is sufficient for a narrower
class of upgrades by messing with %post scriptlets. That is no
more general a solution than the flaw pointed out w %pretrans
in comment #12.

YMMV, everyone's does.
Comment 10 Gwyn Ciesla 2009-04-03 13:28:19 EDT
We're not blindly symlinking here, we're using already packaged files instead of those bundled in the upstream tarball, much like in the new Font handling guidelines.
Comment 11 Jeff Johnson 2009-04-03 14:05:18 EDT
Then I'm missing the relevancy to %pretran in yr comment #12
 pointer.

What is the issue? What I read is Aillon pointing out that
a symlink created to an ispell dperetcory can/will remove
ispell files from a different package erase.

"Don't do that if you don't want that to happen."
is all I meant to point out.
Comment 12 Jeff Johnson 2009-04-03 14:07:19 EDT
grrr ... directory ... of course
Comment 13 Jeff Johnson 2009-04-03 14:16:58 EDT
And just one final note:

The problem in comment #12 has 2 aspects, only one of which
has to do with directory <-> symlink replacement.

The other has to do with multiple packages containing identical
file paths which get collapsed onto the same content when
the directory is replaced with a symlink.

The better solution for comment #12 is to use file (not directory)
symlinks. So the file symlink, not the file from the other package
is removed.

That solution is of course at cross purposes with replacing a directory
with a symlink, but does achieve upgradibility without surprises until
the packaging for both packages, solving both issues, can be fixed.
Comment 14 Gwyn Ciesla 2009-04-03 14:39:06 EDT
True.  And would also be somewhat cumbersome for entire php libraries (great gobs of files), while being quite workable for fonts(one or two at most, typically).

Thanks to everyone for your assistance.
Comment 15 Jeff Johnson 2009-04-03 14:47:37 EDT
The number of symlinks that need creating is not necessarily
cumbersome if created in a script. That's what a splat '*' is for.

Anyways, hoops are involved when there are multiple issues
including %pretrans to replace a directory with a symlink
and simultaneously instantiating a package that does __NOT__
"own" files in the directory being replaced with a symlink
(its the old package erasure that is causing the ispell files to be removed
incorrectly.)
Comment 16 Gwyn Ciesla 2009-04-03 14:56:22 EDT
So how is this an rpm bug and not a gallery2 packaging issue?
Comment 17 Jeff Johnson 2009-04-03 15:03:25 EDT
*EVERYTHING* is an rpm bug, rpm in bugzilla is
the Great Compost Heap of Whatever You Want
to Complain About.
Comment 18 Gwyn Ciesla 2009-04-03 15:13:44 EDT
Strage, I was told that was selinux-policy-targeted. /ducks

No, seriously.  Why is this an rpm bug and not a gallery2 packaging issue?  Is not the correct solution for me to alter the script in the spec to correct the behaviour of the package?
Comment 19 Jeff Johnson 2009-04-03 15:35:32 EDT
This bug was filed against rpm because the error message during
install is obscure. One expects replacing a directory with a symlink
to "just work".

And SELinux policy is known to dump bugs here too. FYI %pretrans
was added not only so that directories could be replaced with a
symlink, but also so that SELinux policy could be instantiated at
a single point in time.

No amount of fiddle-ups with restorecon in %post et al scriptlets
will ever lead to a sane selinux policy upgrade mechanism.

Which is largely why the creeping crud of selinux policy-of-the-day
continues years after %pretrans was implemented for the purpose.
Comment 20 Fedora Update System 2009-04-13 14:02:17 EDT
gallery2-2.3-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gallery2-2.3-5.fc10
Comment 21 Gwyn Ciesla 2009-04-13 14:02:55 EDT
Should be fine now, please test.
Comment 22 Fedora Update System 2009-04-14 11:58:10 EDT
gallery2-2.3-5.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gallery2'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3675
Comment 23 Fedora Update System 2009-04-21 09:28:38 EDT
gallery2-2.3-7.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/gallery2-2.3-7.fc11
Comment 24 Fedora Update System 2009-04-21 09:28:54 EDT
gallery2-2.3-7.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gallery2-2.3-7.fc10
Comment 25 Gwyn Ciesla 2009-04-21 09:29:41 EDT
Please test -7, about to hit -testing.
Comment 26 Fedora Update System 2009-04-21 20:47:57 EDT
gallery2-2.3-7.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gallery2'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3754
Comment 27 Gwyn Ciesla 2009-04-27 10:32:31 EDT
*** Bug 497098 has been marked as a duplicate of this bug. ***
Comment 28 Fedora Update System 2009-04-27 17:40:40 EDT
gallery2-2.3-7.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 29 Gwyn Ciesla 2009-04-28 12:18:05 EDT
I see the flaw, I should move the link creation out of the loop.
Comment 30 Vadym Chepkov 2009-04-28 12:19:43 EDT
The logic is dangerous too:

# pwd
/usr/share/gallery2/lib

# ls -ld smarty
lrwxrwxrwx 1 root root 21 2009-04-28 12:10 smarty -> /usr/share/php/Smarty

# if [ -d /usr/share/gallery2/lib/smarty ]; then
>  echo I will remove Smarty completely
> fi
I will remove Smarty completely
Comment 31 Phil Anderson 2009-05-21 06:02:54 EDT
gallery2-2.3-10.fc10.noarch seems to fix the problem, and is working fine for me.
Comment 32 Gwyn Ciesla 2009-05-21 08:28:19 EDT
Excellent, thanks!
Comment 33 Phil Anderson 2009-05-25 10:32:05 EDT
Actually, I am having problems with 2.3-10.  The upload applet dissapeared.  yum says it's obsoleted by the gallery2 package, however it doesn't seem to work.
Comment 34 Michael Cronenworth 2009-05-26 00:34:44 EDT
gallery2-2.3-11 has major problems. The "remote" plugin is missing and "Add Items" is not usable. Yum says the "remote" plugin is available in "gallery2" but this is not the case. It is not in the plugins list on the WebUI and I cannot find any remote related files in the RPM.
Comment 35 Gwyn Ciesla 2009-05-26 08:43:38 EDT
The remote plugin had to be removed for legal reasons:
https://bugzilla.redhat.com/show_bug.cgi?id=464566
Comment 36 Gwyn Ciesla 2009-05-26 08:45:03 EDT
Same applies for upload.
Comment 37 Michael Cronenworth 2009-05-26 12:04:09 EDT
(In reply to comment #35)
> The remote plugin had to be removed for legal reasons:
> https://bugzilla.redhat.com/show_bug.cgi?id=464566  

Did you link the wrong bug? I don't see anything about the remote plugin there.

Can you add a clean-up script to the gallery2 RPM to remove remote and upload plugins from existing installations? Some people used the remote and upload plugins and now that they are gone it breaks their gallery installs. I don't want to install from scratch and I don't know the intimate details of where the plugin list is stored otherwise I'd fix it myself.
Comment 38 Gwyn Ciesla 2009-05-26 14:47:47 EDT
Whoops.  Yes, I did. 

https://bugzilla.redhat.com/show_bug.cgi?id=484566

I'm looking into that as we speak.  I do have a workaround:

FYI, you can work around this problem by dropping any rows from
g2_FactoryMap where g_implModuleId='uploadapplet' (or any other module
which you've dealt with this way) and then deleting
g2data/cache/module/_all/0/0/* and g2data/cache/module/uploadapplet


Do this for uploadapplet, slideshowapplet and remote.

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