[bug#35305] LightDM service

[Ricardo Wurmus <rekado@elephly.net>]

L p R n d n <guix@lprndn.info> writes:

> Hello,
>
> Ricardo Wurmus <rekado@elephly.net> 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.

Right, I realized this after composing my message.  However, currently
the lightdm-gtk-greeter-service-type inherits all the seats and then
overrides the greeter-session value for each of them, which seems rather
rude.  So maybe it is wrong to let greeters do that at all.

I wondered why there’s a service type for the greeter at all, so I
looked at the service extensions it provides:

* lightdm-service-type: only used to override greeter-session in all
  defined seats, which seems like an anti-feature.  If other greeters
  do the same, then effectively there can only be one greeter for all
  seats, and that would be wrong.  So seat configuration really should
  remain in lightdm-service-type and not be an extension.

* etc-service-type: that’s to provide the greeter’s global configuration
  file.  Ideally, we would not need to use a global configuration file.
  It looks like lightdm-gtk-greeter respects the XDG_CONFIG_DIRS
  variable, so we should be able to generate its configuration file in
  an arbitrary location and then add it to XDG_CONFIG_DIRS in the
  environment of lightdm itself.

* profile-service-type: that’s to install lightdm-gtk-greeter and its
  assets into the system profile.  Again, that’s something we should aim
  to avoid.  It seems that we can avoid it with the use of environment
  variables in the lightdm shepherd service.

If we can avoid all three extensions then we don’t need a
lightdm-gtk-greeter-service-type at all.  If we don’t need a service we
can specify greeters as record type values with a name and configuration
file generator.

-- 
Ricardo