Bug 484240

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.