GNU bug report logs - #63082
mpd defaul configuration does not work ('No database' error)

Previous Next

Full log

View this message in rfc822 format

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 63082 <at> debbugs.gnu.org
Subject: bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.
Date: Sun, 07 May 2023 07:35:21 +0200

Am Samstag, dem 06.05.2023 um 22:55 -0400 schrieb Maxim Cournoyer:
> Hi!
> 
> Liliana Marie Prikler <liliana.prikler <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.