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.
rpm-4.6.0-0.rc3.1.fc10.i386 yum-3.2.21-2.fc10.noarch
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
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.
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?
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.
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?
(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
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?
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.
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.
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.
grrr ... directory ... of course
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.
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.
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.)
So how is this an rpm bug and not a gallery2 packaging issue?
*EVERYTHING* is an rpm bug, rpm in bugzilla is the Great Compost Heap of Whatever You Want to Complain About.
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?
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.
gallery2-2.3-5.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gallery2-2.3-5.fc10
Should be fine now, please test.
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
gallery2-2.3-7.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gallery2-2.3-7.fc11
gallery2-2.3-7.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gallery2-2.3-7.fc10
Please test -7, about to hit -testing.
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
*** Bug 497098 has been marked as a duplicate of this bug. ***
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.
I see the flaw, I should move the link creation out of the loop.
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
gallery2-2.3-10.fc10.noarch seems to fix the problem, and is working fine for me.
Excellent, thanks!
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.
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.
The remote plugin had to be removed for legal reasons: https://bugzilla.redhat.com/show_bug.cgi?id=464566
Same applies for upload.
(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.
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.