Hi, On Tue, Jul 5, 2011 at 6:20 PM, Kay Sievers <kay.siev...@vrfy.org> wrote: > To work in the right direction here, it might be worth to point out in > this context, that the concept of a (multiplexing) prefdm.service > should go away sooner than, and all individual window manager should > install their own native service file from their own package. > > Which of the window managers will be started at bootup will then > entirely be controlled by the 'enable' state of the systemd service > and not by some (awkward) global distro config/service file.
I tried creating a unit file for this, and it's not a big deal at the moment since no other display managers (that I use) have one, but how do you recommend handling situations with multiple display manager services installed? I don't follow if/how display-manager.service is intended to work in this situation. Are users supposed to manage the target of the symlink manually? It is distributed under /lib (along with its link under graphical.target.wants), implying it should not be changed. Ignoring display-manager.service, I imagine distribution packages would have to ship all display managers enabled by default, so users who only install one will have a graphical login automatically. Will anything prevent multiple display managers from actually trying to start concurrently? I used conflicts in my unit file, but that doesn't seem like it will scale well. Sorry if I'm missing something simple or if I have confused myself beyond all hope. I appreciate any advice on how to prepare this in a future-compatible way. David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel