Fedora Account System
Red Hat Associate
Red Hat Customer
Fedora 44 Xfce 4.20 $ rpm -qa xfce4-screensaver xfce4-screensaver-4.20.0-2.fc44.x86_64 This is ChatGPT write up of the issue (he is rather long winded, sorry): Description After removing the xscreensaver package, XFCE sessions can end up with leftover autostart desktop entries that are not cleaned up from: /etc/xdg/autostart/xscreensaver-autostart.desktop ~/.config/autostart/xscreensaver-autostart.desktop These orphaned entries conflict with xfce4-screensaver. As a result, xfce4-screensaver appears to run normally and DBus service is available, but idle blanking and/or screen locking does not function correctly or is inconsistent. Steps to reproduce Install and enable xscreensaver Install xfce4-screensaver Remove xscreensaver: sudo dnf remove xscreensaver Log into XFCE session Observe leftover autostart files remain in /etc/xdg/autostart/ or ~/.config/autostart/ Observe xfce4-screensaver is running but idle lock/blanking does not work correctly Actual result xfce4-screensaver runs and DBus service is active Screensaver idle/lock behavior is broken or inconsistent No warnings about conflicting screensaver autostart entries Expected result Removing xscreensaver should also remove/disable its autostart integration xfce4-screensaver should function normally without manual cleanup Or system should warn about conflicting screensaver session hooks Workaround Manually disabling leftover autostart entries restores correct behavior: sudo mv /etc/xdg/autostart/xscreensaver-autostart.desktop /etc/xdg/autostart/xscreensaver-autostart.desktop.disabled mv ~/.config/autostart/xscreensaver-autostart.desktop ~/.config/autostart/xscreensaver-autostart.desktop.disabled Impact Silent conflict between screensaver session hooks causes xfce4-screensaver to appear functional while idle locking/blanking fails, requiring manual cleanup to resolve. Reproducible: Always
"dnf remove" are not expected to touch user directory. It can happen that user needs to do some "cleanup" manually.
Maybe Xfce is doing adding ~/.config/autostart/xscreensaver-autostart.desktop But to do it, it would have to read /etc/xdg/autostart/xscreensaver-autostart.desktop which "remove" did not remove. And is not in a user directory. Please correct.
were these also suppose to be removed when uninstall xscreensaver? $ rpm -qa | grep -i xscreen xscreensaver-gl-base-6.15-1.fc44.x86_64 xscreensaver-extras-base-6.15-1.fc44.x86_64 xscreensaver-gl-extras-6.15-1.fc44.x86_64 xscreensaver-base-6.15-1.fc44.x86_64 xscreensaver-extras-6.15-1.fc44.x86_64
Again, system wide dnf or rpm command are not supposed to remove files under ~/ (user home directory) Maybe xfce session copies files under /etc/ to /home/user/.config, however anyway it is - not the fault of xscreensaver rpm, maybe DE can handle it. - again dnf / rpm is not supposed to touch files under /home once it is copied.
So definitely xscreensaver does not copy the file, some desktop environment or so copies, and `dnf remove` or `rpm -e` is not expected to remove the files under /home once copied.
In other words, once it is copied to under /home directory, dnf or rpm can no longer judge if it is copied, or it is manually created by user because it is under user home directory. So to prevent removing files "maybe" created by user, dnf or rpm is not expected to remove files under user home directory.
/etc/xdg/autostart/xscreensaver-autostart.desktop was created by $ rpm -qf /etc/xdg/autostart/xscreensaver-autostart.desktop xscreensaver-base-6.15-1.fc44.x86_64 It is not in the user's files dnf remove did not remove xscreensaver-gl-base-6.15-1.fc44.x86_64 xscreensaver-extras-base-6.15-1.fc44.x86_64 xscreensaver-gl-extras-6.15-1.fc44.x86_64 xscreensaver-base-6.15-1.fc44.x86_64 xscreensaver-extras-6.15-1.fc44.x86_64 which are all dependent on having sscreensaver installed
Ah, "xscreensaver" rpm is a meta package which installs the 5 packages above, but $ dnf remove xscreensaver does not remove the 5 packages, it is expected. You can do "$ sudo dnf remove xscreensaver\*"