Subject: On pw_dup(3), and development in general (was: Re: CVS commit:
To: None <email@example.com>
From: Klaus Klein <firstname.lastname@example.org>
Date: 09/14/2003 14:59:29
Klaus Klein <email@example.com> writes:
> Jun-ichiro itojun Hagino <firstname.lastname@example.org> 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
To follow up on this:
1) Your justification for adding this interface was that it "was
needed for BSD auth".
As Frank has already clarified, "no decision about [BSD auth] has
yet been made".
2) I have had a look at the BSD auth implementation proposal which you
posted in . 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 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.
In the meantime all you've allowed for mere 10 hours between your
pw_dup(3) proposal 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 . If it's not, the manner in which you pursued this
issue certainly was not helpful in not creating this impression.
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.