Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#33405 - [systemd] pacman -R current display manager does not remove display-manager.service

Attached to Project: Arch Linux
Opened by Chris Warrick (Kwpolska) - Tuesday, 15 January 2013, 16:10 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 16 January 2013, 15:19 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

(via https://bugs.freedesktop.org/show_bug.cgi?id=58955 )

When the currently used display manager is removed, the file /etc/systemd/system/display-manager.service stays in the system and is a broken symlink. In order to fix it, one needs to --force enabling a new DM.

[root@kwpolska-lin kwpolska]# systemctl enable lxdm.service
[root@kwpolska-lin kwpolska]# pacman -R lxdm
[root@kwpolska-lin kwpolska]# systemctl enable kdm.service
Failed to issue method call: File exists
[root@kwpolska-lin kwpolska]# systemctl enable --force kdm.service
rm '/etc/systemd/system/display-manager.service'
ln -s '/usr/lib/systemd/system/kdm.service' '/etc/systemd/system/display-manager.service'
[root@kwpolska-lin kwpolska]# pacman -Q systemd lxdm
systemd 197-4
lxdm 0.4.1-18
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 16 January 2013, 15:19 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Not a systemd bug, and Arch has a mantra of not touching user config. As Jan points out, whether it's a symlink or a line in a file, this is still user configured and the user's responsibility.
Comment by Dave Reisner (falconindy) - Tuesday, 15 January 2013, 16:19 GMT
There's no bug here. You created this symlink. pacman knows nothing about it, and is never going to remove it.
Comment by Chris Warrick (Kwpolska) - Tuesday, 15 January 2013, 16:21 GMT
Lennart thinks otherwise, via https://bugs.freedesktop.org/show_bug.cgi?id=58955 :

> That said, your packaging scripts are broken. The old display manager should have removed the symlink on removal. This is usually done from the package removal scripts of your display manager rpm. Please report this to your distribution, to the package of your old DM.
Comment by Dave Reisner (falconindy) - Tuesday, 15 January 2013, 16:29 GMT
So if I have GDM and LXDM installed, removing either one of them should remove the display-manager.service symlink? That breaks the currently in use service.

It's neither a pacman nor a systemd bug. It's a user responsibility to take care of things you create on your system.
Comment by Daniel Wallace (gtmanfred) - Tuesday, 15 January 2013, 16:30 GMT
unless you put it in a conditional statement and only remove it if it is linked against gdm or lxdm.service :P
Comment by Chris Warrick (Kwpolska) - Tuesday, 15 January 2013, 16:30 GMT
IMO (and probably what Lennart was thinking of) it should check what the symlink is. If it is pointing to the DM currently removed, the symlink should die. If not, leave the symlink as it was ten seconds ago.
Comment by Dave Reisner (falconindy) - Tuesday, 15 January 2013, 16:39 GMT
If that's your proposal, then it's still not a systemd or pacman bug -- you'll need to take it up with every maintainer of a DM package.
Comment by Jan de Groot (JGC) - Wednesday, 16 January 2013, 15:15 GMT
IMHO this is user configuration:
- you install gdm
- you add gdm to rc.conf DAEMONS
- you remove gdm
- DAEMONS still contains gdm!

Now systemd:
- you install gdm
- you enable gdm in systemd config
- you remove gdm
- gdm is still enabled, but it's not there anymore

How is this different? The fact that it is a symlink instead of a variable in a config file does not mean it's no longer user configuration.

Loading...