Thanks for the explanation. This rationale sounds reasonable to me. If someone with proper permission has modified a user account's comment, it could be important to preserve that customization.
As I pointed out in an earlier message, I believe this behavior contradicts the documentation of the `user-account' data type pretty strongly. So it appears there is at least a "doc bug" here. FWIW, I actually reported the present behavior as a bug not because of the doc issue, but based on an assumption that "purely declarative" implied the result of applying a given configuration should not depend on any preexisting system state like a user comment. Sorry for not making that clear: it seemed obvious, but I think it's actually a misconception (even if user accounts are one of the few areas, AFAICT, where the property doesn't hold true). On Wed, Dec 22, 2021 at 10:36 PM Ludovic Courtès <l...@gnu.org> wrote: > > Hi, > > Jacob First <jacob.fi...@member.fsf.org> skribis: > > > After I apply this configuration with `guix system reconfigure', I > > expect /etc/passwd to have been updated with "New Comment" in place of > > "Old Comment". However, "Old Comment" remains. > > This is on purpose, per these lines in ‘allocate-passwd’ in (gnu build > accounts): > > (real-name (if previous > (password-entry-real-name previous) > real-name)) > > This wasn’t a firm decision, but I think the rationale here could be > that we’d rather allow users to change their name with ‘chfn’ to > something other than what the sysadmin chose, than enforce the > sysadmin’s choice. (Except that ‘chfn’ is currently not setuid by > default on Guix System, so the scenario above is unlikely.) > > Thoughts? > > Thanks, > Ludo’.
