Hello,

Here I come again with a new attempt for the LightDM service.
This one is a little too complex to my taste but it succeeds IMHO at
dealing with most cases nicely. Also I didn't find any other occurence
of this in Guix, so it might just not fit in. It's a draft and it's
ugly, it probably needs some refactoring/renaming, maybe using methods?
or just alists?

In the meantime, the chosen design is to have the lightdm-service and
greeter services to extend another, private service (lightdm-aggregate)
that deals with mergin everything all configuration and extending the
needed services accordingly. This way, data can be shared between
lightdm's and greeters' configurations (here, greeters' desktop file
directories and a list of greeters needed by the seats definition)

It features:

* A user can define only the a lightdm-service or only a greeter service
  or both, he should always get a working LightDM. If a seats asks for a
  greeter which is not defined in the user config, the lightdm-aggregate
  service adds its service with default config.

* Seats are defined only in the lightdm service so, on one hand, the user needs to
  manually set the `greeter-session field but, on the other hand, we get
  a clear distinction between configurations.

* Too many (cond ...). There might be better solutions.


Please give me your opinion. I think I'll try one last design which will
be the complete opposite of this one. (lightdm-service deals with its
conf, greeters deal with theirs. The user deals with the rest. Also
(service lightdm-service-type) is not enough for a working
display-manager).

Have a nice day,

L  p R n  d n