Description of problem: When xscreensaver-extras is UPGRADED while gnome-screensaver is already installed, the xscreensaver modes disappear from gnome-screensaver's menu. This is a problem with the ordering of the trigger scripts in gnome-screensaver. Version-Release number of selected component (if applicable): gnome-screensaver-2.14.0-1 How reproducible: Always Steps to Reproduce: 1. Have gnome-screensaver-2.14.0-1 and xscreensaver-extras-4.24-1.1.i386.rpm from fresh FC5 installed 2. Upgrade to xscreensaver-extras-4.24-2.i386.rpm from updates-testing Actual results: xscreensaver modes disappear from gnome-screensaver options. The xscreensaver-*.desktop files are missing from /usr/share/gnome-screensaver/themes Expected results: modes should stay xscreensaver-*.desktop files should be in /usr/share/gnome-screensaver/themes, created by the migration script Additional info: This is because the %triggerun for the old xscreensaver-extras being uninstalled is getting run AFTER the %triggerin for the new xscreensaver-extras being installed. (See http://www-128.ibm.com/developerworks/library/l-rpm3/ for a discussion of the ordering of RPM scripts during an update.) The %triggerin for the new install runs migrate-xscreensaver-config.sh and creates the requisite files in /usr/share/gnome-screensaver/themes -- but then the %triggerun for the old xscreensaver-extras being uninstalled goes right and deletes them. I can confirm that upgrading with `rpm -Uvh --notriggerun xscreensaver-extras-4.24-2.i386.rpm' works perfectly and leaves the desktop files in place as it should.
ugh, that's a bit unfortunate. Let me add this to the FC5 Update tracker.
So, judging by the discussion at http://www-128.ibm.com/developerworks/library/l-rpm3/, I assume that the solution is something like: %triggerun -- xscreensaver-extras if [ "$2" = "0" ] ; then # last uninstall of triggering package (cd %{_datadir}/gnome-screensaver/themes; \ for f in $(rpm -ql xscreensaver-extras | grep '%{_datadir}/xscreensaver/config/'); do rm -f xscreensaver-$(basename $f .xml).desktop done) fi and similarly for xscreensaver-gl-extras. That should only remove the files if xscreensaver-extras is being completely removed. Possible problem-- AIUI, if one updates to a newer version of xscreensaver-extras that drops some mode, then erases the newer version, the dropped mode will stick around and not be deleted by the script.
Hmm, I also got this same bug when upgrading just gnome-screensaver to the new gnome-screensaver-2.14.0-1.fc5.1 package. Once again, all the xscreensaver modes vanish, along with the files in gnome-screensaver/themes. I assume that once again it has to with %post scripts being run before deletion. In this case, gnome-screensaver owns the entire gnome-screensaver/* path, and RPM isn't noticing that the new version changes/wants to keep those files, and goes ahead and removes them. Hmm. I can think of a few ways around this, but it is getting a little ugly.
Can someone suggest a quick way to get the xscreensaver modes back once this happens, and attach it as a comment to this bug for people like me that are trying to fix their installations? Thanks.
The easiest methods is: rpm -e xscreensaver-extras([-gl] if you have that installed too) yum install xscreensaver-extras ([-gl] again) Just uninstall and then reinstall xscreensaver extras.
It looks (based on rpm -Uvvh) like what's happening here is that the postun trigger that removes the migrated xscreensaver-*.desktop files in /usr/share/gnome-screensaver/themes is running *after* the postinstall scriptlet that makes them, so the upgrade path (1) overwrites all the existing ones and then (2) removes the files it's just created: D: install: %post(gnome-screensaver-2.14.3-1.fc5.i386) synchronous scriptlet start D: install: %post(gnome-screensaver-2.14.3-1.fc5.i386) execv(/bin/sh) pid 7456 [...bash script, line by line, including loops...] D: install: waitpid(7456) rc 7456 status 0 secs 29.269 D: read h# 4506 Header V3 DSA signature: OK, key ID 4f2a6fd2 D: install: %post(gnome-screensaver-2.14.3-1.fc5.i386) synchronous scriptlet start D: install: %trigger(gnome-screensaver-2.14.3-1.fc5.i386) execv(/bin/sh) pid 8820 [...bash script, line by line, including loops...] D: install: waitpid(8820) rc 8820 status 0 secs 17.745 D: read h# 5477 Header V3 DSA signature: OK, key ID 4f2a6fd2 D: ========== --- gnome-screensaver-2.14.2-1.fc5.1 i386-linux 0x1 D: erase: gnome-screensaver-2.14.2-1.fc5.1 has 86 files, test = 0 D: erase: %preun(gnome-screensaver-2.14.2-1.fc5.1.i386) asynchronous scriptlet start D: erase: %trigger(gnome-screensaver-2.14.2-1.fc5.1.i386) execv(/bin/sh) pid 10180 [...bash script, line by line, including loops...] D: erase: waitpid(10443) rc 10443 status 0 secs 3.015
David Baron: Yes, but for complicated reasons, that's expected and required behavior for rpm... If you look at some rpm pages you'll see. The 4.24-3 packages recently pushed to updates-testing fix the problem by adding subpackages-- xscreensaver[-gl]-extras-gss contain the gnome-screensaver versions of the files. The only annoyance here is that it won't automatically install the -gss subpackges if you have the base packages installed. Still, this is pretty close to solved
Since, after all, the packages already required lots of manipulation on the user's part and wouldn't work without manual reinstallation anyway, I'm going to close it.