On pw_dup(3), and development in general (was: Re: CVS commit: src/lib/libc)

[Klaus Klein <kleink%reziprozitaet.de@localhost>]

Klaus Klein <kleink%reziprozitaet.de@localhost> writes:

> Jun-ichiro itojun Hagino <itojun%netbsd.org@localhost> writes:
>
>> Module Name: src
>> Committed By:        itojun
>> Date:                Sat Sep 13 22:28:13 UTC 2003
>>
>> Modified Files:
>>      src/lib/libc/gen: pw_dup.c
>>      src/lib/libc/include: namespace.h
>>
>> Log Message:
>> weak alias for pw_dup
>
> There's no need for this since there is no libc-internal use of
> pw_dup(3).

To follow up on this:

1) Your justification for adding this interface was that it "was
   needed for BSD auth".[1]

   As Frank has already clarified, "no decision about [BSD auth] has
   yet been made".[2]

2) I have had a look at the BSD auth implementation proposal which you
   posted in [3].  All BSD auth logic resides in libutil, and there is
   no reason to have pw_dup(3) separated from it in libc; neither does
   pw_dup(3) access any libc internals in which case it being
   implemented in libc would be a sensible choice.  It's also worth
   noting that the bulk of password database utility functions already
   reside in libutil.

3) Luke has stated[4] that he intends to integrate the FreeBSD
   enhancements to nsswitch, which include reentrant interfaces to the
   password database.  With these in the tree, the need for a
   pw_dup(3) helper would cease[5].

In the meantime all you've allowed for mere 10 hours between your
pw_dup(3) proposal[6] and the import, which is _not_ sufficient for
discussion; a look at a timezone chart alone should make that clear.
Personally, I can't help the feeling that this is part of an attempt
to force a breach through which you intend to import BSD auth later
on, despite [2].  If it's not, the manner in which you pursued this
issue certainly was not helpful in not creating this impression.


My conclusions:

1) pw_dup(3) should be moved to libutil (desire to have this in the
   base system was voiced, so I won't argue towards removal).  The
   window since the evening of the 9th is still small enough to let
   this one slide.

2) The culture of ad-hoc development hurts in the long term, and in
   two ways: the base system will suffer from quality issues (this
   includes unnecessary bloat from interfaces added in the wrong
   places), and the individual developer will become vulnerable to
   frustration by a continuous critique onslaught after premature
   changes.  It takes little effort to avoid this problem.



- Klaus

[1] http://mail-index.netbsd.org/tech-userlevel/2003/09/10/0002.html
[2] http://mail-index.netbsd.org/tech-userlevel/2003/09/09/0024.html
[3] http://mail-index.netbsd.org/tech-userlevel/2003/09/09/0001.html
[4] http://mail-index.netbsd.org/tech-userlevel/2003/09/11/0000.html
[5] http://mail-index.netbsd.org/tech-userlevel/2003/09/09/0025.html
[6] http://mail-index.netbsd.org/tech-userlevel/2003/09/09/0020.html