This one time, at band camp, Robert Millan said: > I'm not sure what's the best way to proceed (if I was, I'd already > send a patch). I was hoping we could find a way to extend and/or > abuse the GECOS in a back-wards compatible manner. > > Such "gender" field may have three values (male, female or undefined).
I think that this opens a whole set of issues that have previously been happily ignored; you are creating an enum here, essentially, but not putting in possibilities for trans gender or other non biological identifiers, which is an issue I would be really happy to not deal with, frankly. > The latter could mean we don't know, or we don't care. Perhaps one of > the fields can be abused/extended to add this information (in which > case this is an adduser issue), or chfn could be modified to provide > an additional field (in which case this issue belongs to the shadow > suite). The whole thing belongs at a lower layer than adduser, I think. Th efirst thing I would do is try an experiment on one of your systems and see what goes wrong. I suspect finger and some other tools may not behave all that well if you add an extra field or change the semantics of a pre-existing field (I mean a field within the gecos entry, in case it's not clear). If all goes well, contrary to my expectations, then I would take it up with the shadow maintainers - adduser currently really only calls chfn to handle the gecos entries, so if the support is there, it will be present in adduser. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
