[bug#35305] LightDM service

[L p R n d n]

Hello,

Ricardo Wurmus <address@hidden> writes:

> Hey,
>
> I’m very sorry for the delay.

Again, there's no hurry. ;)

> What took me so long is that I’m conflicted about how to move forward.
> On one hand I really don’t want to delay this.  I think your patches are
> a great and important addition to Guix.  On the other hand I feel that
> the relationship between these new components isn’t quite right.
>
> It still doesn’t feel quite right to me that there’s a
> lightdm-service-type and an independent
> lightdm-gtk-greeter-service-type.  I know that there can be any number
> of greeters, but only one will be used with lightdm-service-type
> dependent on the string value of greeter-session.  This leads to
> potential misconfiguration as we don’t (and can’t) validate this string.

Just to clarify, as per my understanding, there can be multiple
`greeter-session fields defined. It's not a global value but a per seat
one. Each seat should be able to use a different greeter, I
think. Personally, I have a very standard use whith only one seat so
there are no questions in that case. However there might be use-cases
where it's needed. I CC bricewge, they might be more knowledgeable on
this issue.

> It also feels wrong to me to have a global directory as the only
> location for greeter desktop files, which means that all greeters must
> be installed globally.

Isn't using packages as inputs of `greeter-session solving this issue?
We can collect them from seats and string-join them into the
`greeter-directory field.

> What I envision is something like this: we only have a single
> lightdm-service-type and it has a field “greeters”, which by default is
> a list of just one item: a <greeter> record containing the
> lightdm-gtk-greeter and its configuration.
>
> Other greeters could be added; they would all be record values of type
> <greeter> and come with their own extensions of the
> ligthdm-service-type.
>
> The lightdm-service-type would go through each of the greeters in the
> list and apply their specified extensions to itself.

If I understand correctly, the main difference would be that the
greeters would be defined from within the lightdm-service (as a list of 
records?), right?
The current implementation was chosen to avoid too much field nesting
but I don't mind.
Also, you can have a look at the previous implementation (see
mail from 19th of March). It lacks seats and some featurse but it looks a
little closer to what you're describing. It might give some ideas.

> The reason why I haven’t implemented this yet is because a) I don’t want
> to break what already works with your patches and b) I don’t know if
> that’s ultimately a clearer implementation.
>
> I feel that this would be a more intuitive configuration and result in
> clearer relationships between the display manager and its swappable
> components.  It would also allow for better defaults (so less
> configuration needed) and avoid the problem of stringy types that are
> easy to get wrong.
>
> Maybe we are already really close to this solution, though: maybe the
> proposed “greeter” field could simply accept service types like the
> lightdm-gtk-greeter-service-type you already defined.

We're close. :)
Just curious here, if we use a list of services (for example) as input of
the greeters field, how do we take care of it? Can we "merge" the
different services into the lightdm one? If it's possible, this might be
a good solution.

> I’m going to play with this a little bit more, but if this doesn’t lead
> anywhere I’ll merge the current version.
>
> My apologies for delaying this!

Everything is going a lot faster than it was a few months ago so it's
already fine.

Have a nice day,

L  p R n  d n