> > 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.
> 
> Why not just put it in /etc/passwd, which isn't a critical file since
> it's derived from /etc/master.passwd?   Admittedly, this is still
> somewhat lame, but at least less so...
> 
> > 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 think this is the right thing to do, although I'll probably go down
> in flames for saying so.   An alternative would be to maintain a list
> in hesiod of all the usernames, and then use that list do implement
> getpwent.   Ugly, but it would work.   Ultrix does something like
> this.
> 
	Isn't getpwnam() and company part of SPEC 1170? By ditching it
	aren't we trashing the ability of NetBSD to be standards
	conformant?

	I know BSD'ers hate, loath and despise all things SVR4 and Solaris-ish
	but I think something like a database service switch similar to
	nsswitch.conf in Solaris is the better way to go for ALL services.
	That way we can add arbitrary network database services by adding
	a dynamic library and a directive to a config file.

	Work on this is already being done, why not accelerate that work
	rather than removing functions that don't need to be removed? Plus
	this method won't require N different function calls to do the
	same thing for N different services.

		-Rob