bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

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

Am Samstag, dem 06.05.2023 um 22:55 -0400 schrieb Maxim Cournoyer:
> Hi!
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Freitag, dem 05.05.2023 um 14:29 -0400 schrieb Maxim Cournoyer:
> > Didn't we agree in v2 that we want to address this on the account-
> > service level?  Unless the rest of this series somehow depends on
> > this patch, I'd rather delay it until we have a proper solution.
> 
> I think we agreed the idea to have <user-account> support <user-
> group> objects for its group field was a good idea that should be
> implemented, but I declined doing this new work as part of this
> series :-).
Indeed, that's how I understood it.  However, I also thought that
addressing this issue in a later series means we can keep the current
behaviour until that is done.

> > > Synchronizing both is not practical, as it can easily lead to
> > > slightly different <user-account> objects conflicting, again
> > > causing problems.
> > It might not be practical to do so inside the service, but note how
> > this has already become an effort in defensive programming.  There
> > are easier ways to not make this a problem on the configuration
> > level, namely by specifying the same group for both user and group
> > fields.  As far as I see this is even the default state of being if
> > the user is supplied as a string.
> 
> I really don't like the group information being duplicated in both
> the user and a distinct field; it's an awkward API that raises more
> questions than it provides answers, in my opinion (non-intuitive).
And I agree that it's awkward, but I don't agree that this patch solves
the underlying issue.

> One of the reasons I came think this way is because a <user-group>
> can differ by being a system group or not, which would make it easy
> to introduce unexpected, subtle variants.
Is that a serious issue, though?  Yes, two configuration files, one
with (system? #t) and one without will produce different results in
that GIDs are allocated differently, but the same applies to the user
as well.  The only real issue I can think about here goes back to the
handling of duplicate accounts and groups; and again, we both agree
that those ought to be hard errors rather than warnings.

Cheers