Bug 187332
Summary: | gnome-screensaver loses xscreensaver modes when upgrading xscreensaver | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Thacker <johnthacker> |
Component: | gnome-screensaver | Assignee: | Ray Strode [halfline] <rstrode> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | dbaron, jmccann, thoffman |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-08 01:21:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 182226 |
Description
John Thacker
2006-03-30 05:15:17 UTC
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. |