[systemd-devel] Environment for prefdm.service

[David Michael]

Hi,

On Tue, Jul 5, 2011 at 6:20 PM, Kay Sievers <kay.sievers at 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