[bug#35305] LightDM service

[L p R n d n <guix@lprndn.info>]

Hello,

I spent some time thinking about the lightdm service and what are our
possibilities so here are my thoughts and conclusions.

(Here, I'll only describe relations between seats, greeters and the lightdm
service as it's our main source of problems)

So if we get rid of the greeter's services, we can have:

1:
(service lightd-service-type
    (lightdm-configuration
        (greeters
            (list
                (lightdm-gtk-greeter-configuration
                  (seats
                      (list
                          (lightdm-seat-configuration ...))))))))

Here seats are defined by greeters. This way the user doesn't need to
fill `greeter-session field as we can do it automatically. But there's a lot of nesting
(and two lists.) + How do we define autologin?

2:
(service lightd-service-type
    (lightdm-configuration
        (seats
            (list
                (lightdm-seat-configuration
                    (greeter-session
                        (lightdm-gtk-greeter-configuration ...)))))))

Defining greeters inside seats allows in the `greeter-session field make
it a little simpler. However, we would get errors or conflicts if a user
define two different configurations of the same greeter for two
different seats. The thing is that we can only have one configuration
per greeter as it will always look for a hardcoded file in /etc/ (worst
case) or a file we hardcoded at build time (best case). :/

3:
(service lightd-service-type
    (lightdm-configuration
        (seats
            (list
                (lightdm-seat-configuration
                    (greeter-session 'lightdm-gtk-greeter))))
        (greeters
            (list
                (lightdm-gtk-greeter-configuration
                  )))))

We can have separate fields for greeters and seats. The user will have
to define `greeter-session by himself. And what happen if they define
multiple occurences of one greeter's configuration?


So my conclusion is that the current implementation using a different service for lightdm and its
greeters is probably not so bad as it prevents most of these
issues. Unless someone has an even better idea, indeed. :D

Ricardo Wurmus <rekado@elephly.net> writes:

> L p R n d n <guix@lprndn.info> writes:
>
>> Hello,
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
[...]
> 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.

As disussed on IRC, a greeter service only overwrites its own
`greeter-session field. But we could get rid of the `greeter-session
field altogether as it's probably not necessary if they're filled by the
greeters' service or record (depending of what we choose).

> * 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.

I didn't find any informations about lightdm-gtk-greeter using
XDG_CONFIG_DIRS. Could you provide further explaination as it could
impact what I wrote earlier.

> * 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.

Yeah ;)

> 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.

Hope it's clear, I'm really just dumping my thoughts... :)
Please tell me what you think.

Have a nice day,

L  p R n  d n