Hi Leo, > > Considering the goal of Guix, it's weird that with Guix, one needs to > > store&restore /etc/passwd at all. It's state, but not very useful > > one. > > I mean that's how it is right now--but it's still weird. > > With /etc/shadow maybe there's a slightly better case, but note that > > the key > > to find stuff in /etc/shadow can't be the uid--the uid isn't even in > > there! > AFAIU yes, it's state, but not one that Guix can simply do away with. It's easily possible to recreate /etc/passwd from scratch if the uids are always specified in s and thus /etc/passwd would not need to be persistent state anymore. Right now everything from /etc/passwd except the uid and the comment is already specified in . So Guix can indeed simply do away with the persistent state of /etc/passwd--that's why I suggested specifying the uids in the first place. (By now I don't think that's the best way to make UIDs stable, but it's factually incorrect to assert that Guix can't simply do away with that persistent state specifically. It can.) > There is not yet a syntax for keeping secrets, which would be needed to > fully populate /etc from config.scm. Perhaps we'll get there some day. /etc/passwd does not contain secrets. Neither does /etc/group. And /etc/shadow doesn't contain uids. So there is no conflict.