[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#35305] LightDM service
From: |
L p R n d n |
Subject: |
[bug#35305] LightDM service |
Date: |
Fri, 19 Jun 2020 16:47:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
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
0001-services-Add-lightdm-service-type.patch
Description: Text Data