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