This problem also effects F10:

I get this output from "yum -y update":

Transaction Check Error:
  file /var/www/moodle/web/lib/magpie/rss_fetch.inc from install of moodle-1.9.4-3.fc10.noarch conflicts with file from packagephp-magpierss-0.72-4.fc10.noarch

Previously, moodle had been using it's own bundled magpierss.  I removed it and symlinked to php-magpierss, which I set moodle to Require.  It was then discovered that php-magpierss is incompatible with moodle, and moodle really needed to use the bundled version, so I dropped the Requires for php-magpierss and replaced the bundled magpierss.  I have a %pre script to check for the symlink and remove it.  

A workaround for this is to rm /var/www/moodle/web/lib/magpie, which should be a symlink, and then upgrade.  I'm not sure why the %pre isn't taking care of this.

Thanks, after removing the link update with rpm and/or yum goes well. If "Obsoletes: php-magpierss" in spec file is too strong, manual removing of php-magpierss should be advertised.

Does rpm in the phase of upgrading understand all the bash features? Maybe test with -L or just -a is worth trying.

No, obsoleting or removing php-magpierss isn't necessary and would break or remove other packages that require it, if installed.  It's not that the moodle bundled version replaces php-magpierss, it's that we're removing the link from moodle to php-magpierss.  The two versions live in different places.

rpm scripts do honor all bash features.  Here's the pre script as it stands:

if [ -d /var/www/moodle/web/lib/smarty ]; then
  rm -rf /var/www/moodle/web/lib/smarty
fi
if [ -d /var/www/moodle/web/lib/adodb ]; then
  rm -rf /var/www/moodle/web/lib/adodb
fi
if [ -h /var/www/moodle/web/lib/magpie ]; then
  rm -f /var/www/moodle/web/lib/magpie
fi


The first two sections test if certain directories exist and remove them (so the symlinks can be installed), and the last checks for the magpie symlink and removes it (so the files can be installed).  From what I can tell, -L and -h do the same thing.  -a tests for a regular file.

Well, it was just an idea, it now looks to me that the upgrade process fails in the stage of checking conflicts, i. e. sooner than %pre. Renaming the moodle-packages' magpie directory to a different word may be a solution.

(BTW: -a:  True if file exists, and it really matches a link)

Found this bugzilla while looking for the problem I had with updating moodle.  The error I get is identical to the one from Steve in comment #1.
And I can confirm that removing the link with rm /var/www/moodle/web/lib/magpie allows the update to complete.  Thanks.

By the way, this is happening in F10 as well.

Is a new update going to be issued to fix this, or are we just going to do the workaround?  I only found this Bugzilla entry via a link elsewhere.

*** Bug 490151 has been marked as a duplicate of this bug. ***

Apparently I didn't find this one when I posted 490151 because this is marked as F9 only.  This continues into F10

I was hit by this a while back, on two machines. I'm pretty sure I solved this on one by

  yum shell
  erase php-magpierss
  update

but it was a little while ago and I can't now be certain. Obviously that relies on not having anything else installed that depends on php-magpierss, but certainly in my case that was true.

On the other machine

  rpm -e --nodeps php-magpierss
  yum update

was enough. If that bothers you, you can

  package-cleanup --problems

afterwards to check you haven't left anything hanging.

That's pretty much the same as rm -f /var/www/moodle/web/lib/magpie
from moodle's perpective, once the symlink's gone it doesn't care. 

I'd just like a way to avoid these workarounds.

Is a future update going to address this?  Moodle has already been updated once again, and this upgrade is still failing.  I'm not averse to doing the workaround, I just think it's a step that's unnecessary.

I ran the pre script in comment #4, and it worked just fine.  I just copied-and-pasted the code and ran it as root on the command line, and the upgrade worked just fine after that.  Hope a fix for this comes that doesn't require manual intervention, though.

See if you can rpm -Uvh  the version that just hit rawhide without the workaround. 1.9.4-7.

Ping?  If this works, I'd like to get it in F-11.

All happy here: I've just used yum to update to the rawhide version. But I don't know that that tells you much, because I'd already got as far as 1.9.4-6 (see comment 10) so magpierss was already gone.

That said, there seem to be other changes in 1.9.4-7, because it's now pulled in a couple of GNU font packages.

That's due to a font change in rawhide.  I'll build -7 for F-10 and push to testing, so future testers won't see that.  Until the upgrade to F-11, that is. ;)

And F-9.

moodle-1.9.4-7.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/moodle-1.9.4-7.fc9

moodle-1.9.4-7.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/moodle-1.9.4-7.fc10

moodle-1.9.4-7.fc9 has been pushed to the Fedora 9 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-newkey update moodle'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3808

moodle-1.9.4-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 moodle'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3867

moodle-1.9.4-7.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

moodle-1.9.4-7.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.