Bug 187332

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.