bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Samstag, dem 29.04.2023 um 13:16 -0400 schrieb Maxim Cournoyer:
>> This means we do not have to expose user-accounts at the
>> <mpd-configuration>, which is not the right place for that anyway;
>> it's already exposed via the users/groups fields of the <operating-
>> system> record.
>>
>> That's much easier to reason with, for both humans and the code, in
>> my opinion.
> We have the tools to make this meaningful with user-accounts already –
> we've had them for some while in fact.
>
> (operating-system
>   ...
>   (users (cons* alice bob mpd %base-user-accounts))
>   (services (cons* (mpd-service (user (find mpd-user? users)))
>                    %base-services))
>   ...)
>
> is a perfectly fine configuration given concrete values for alice, bob,
> and mpd with mpd-user? matching the MPD user account by name.  The
> point in providing user-accounts in the MPD service is so that the
> right thing is done w.r.t. account creation regardless of whether the
> user exists in users or not.  In the former case, it is checked that
> definitions match (using pointer identity), in the latter the user is
> automatically added.  "I will assume that a user by this name exists
> even if it does not" is a recipe for shooting oneself in the knee.

I agree looks nice "on paper", but in practice, I was confronted with
the following problem, which is enough annoying to make me want to go
back to the simpler string contract:

A <user-account> record encodes a lossy version of a <user-group> as a
string, as its 'group' field.  This way of specifying a group implies it
already exist, since it doesn't capture all the <user-group> details,
e.g.: is it a system group or not?

In the current mpd-configuration, to use my own user, I must also
provide the matching group as a <user-group> record, even if
e.g. 'users' is something I've never created myself and don't really
have a clue as to how it was defined without looking at the source, yet
it's important that it matches the original definition otherwise I'd
have two same-named groups differing only subtly, which would introduce
issues probably harder to diagnose than "sorry, no such group!"

One way that seems like it'd solve it is to make the group field of a
<user-account> accept a <user-group>; then the user object would be
self-contained as far as extending user-accounts goes; the API becomes a
bit more obtuse though, especially when you simply want to specify a
group known to exist ('users', 'audio', 'netdev', etc.).  We'd probably
now need to export %users-group, %audio-group, etc. to make this API a
bit more manageable/convenient.

-- 
Thanks,
Maxim