Bug 187332 - gnome-screensaver loses xscreensaver modes when upgrading xscreensaver
gnome-screensaver loses xscreensaver modes when upgrading xscreensaver
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks: FC5Update
  Show dependency treegraph
 
Reported: 2006-03-30 00:15 EST by John Thacker
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-07 21:21:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Thacker 2006-03-30 00:15:17 EST
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.
Comment 1 Ray Strode [halfline] 2006-03-30 00:27:07 EST
ugh, that's a bit unfortunate.  Let me add this to the FC5 Update tracker.
Comment 2 John Thacker 2006-03-30 11:10:57 EST
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.
Comment 3 John Thacker 2006-04-07 12:56:10 EDT
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.
Comment 4 Torrey Hoffman 2006-04-21 17:37:57 EDT
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.
Comment 5 John Thacker 2006-04-21 20:01:44 EDT
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.
Comment 6 David Baron 2006-08-15 16:16:46 EDT
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
Comment 7 John Thacker 2006-09-07 21:19:56 EDT
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
Comment 8 John Thacker 2006-09-07 21:21:48 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.