I've been mulling over what it would take to add Hesiod support to NetBSD,
and I am somewhat unhappy about some of the answers I've come up with.  I'd
like to hear some suggestions, if anyone has them.

To begin with, I don't think that the way Hesiod is used at MIT is "right".
At MIT, login uses hes_getpwnam() to get the user's password entry, and then
*adds it to the local /etc/master.passwd* and then runs pwd_mkdb.  This
seems absolutely wretched, though it does deal with the ugly compatibility
issue of not having a getpwent() equivalent.  I think that this solution is
completely unacceptable for inclusion in NetBSD if for no other reason because
it requires login to fork, wait for the user to log out, and then remove the
password file entry.  The whole business of constantly modifying the password
file seems like a disaster waiting to happen, and I imagine (though I don't
_know_) that similar chicanery is required of ftpd and anything else that
wants to use Hesiod to get user information -- it's not used on normal machines
at MIT, but popper, for example, would need to get customized in order to work
in this environment.

The unfeasibility of a getpwent() equivalent, however, raises some nasty issues.
It would be pretty easy to add Hesiod support to getpwnam() and getpwuid(), I
think, and that at least should be done.  But there are a lot of programs in
the source tree that use getpwent -- csh being the most important -- and those
simply _can't_ work with Hesiod unless rewritten to use getpwnam() or
getpwuid(), which does at least seem feasible.

What I think I've come to is the realization that if we're going to add
Hesiod support to NetBSD, we have to declare getpwent() deprecated, add a
linker warning like for setreuid(), and excise it from our source tree.

I am not at all convinced that this is bad, though it's a bit more work than
I thought would be involved, initially.  I don't think it's reasonable to
assume that all sources of user information will approximate flat files, and
the fact that Hesiod is the only one currently in use which breaks getpwent()
doesn't mean that getpwent() use should be in any way encouraged.

I would be interested to hear what other people think about this subject, and
also of any legitimate use for getpwent() that can't be worked-around.

Thor