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

[Maxim Cournoyer]

Hi Liliana,

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

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

I think I'd favor the second option then (migrating <user-account> to
support both <user-group> and strings), so that every service could
benefit from the change, as you've noted.  I don't intend to work on it
in the scope of this series, but I think it'd be a welcome improvement!

-- 
Thanks,
Maxim