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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Maxim,

Am Sonntag, dem 30.04.2023 um 21:07 -0400 schrieb Maxim Cournoyer:
> > 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!"
The "find by name" pattern applies here as well. We could extend the
semantics of group field so that if a string is passed, %base-groups is
searched for a matching name first instead of constructing a new group.
This would allow you to more easily specify (group "users") for
example.

> > 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.).
Not really. If the <user-account> allowed for a <user-group> group, we
could drop the group field in the MPD specification. The semantics for
string groups would remain unchanged, whereas <user-group> groups would
get added to the accounts service as though they had been specified via
the groups mechanic. We'd only have to twiddle with account service
there and the change would probably benefit every service that requires
an account:group pair.

Cheers