[ On Tuesday, August 28, 2001 at 00:07:08 (-0400), John Hawkinson wrote: ]
> Subject: Re: lib/13794: RES_OPTIONS=debug is broken due to res_init.o build issue
>
> I see you chose not to reply to me personally in your message.
> Kindly don't do that. It impedes rapid dialogue and convenience.

So sorry -- I usually prefer to correspond with list postings only via
the list (and in this case through GNATS too).....

I'm not so much interested in rapid dialogue (especially in a case like
this where I'm simply reporting an example of something I did months
ago).  I'm more interested in public discourse and as such I prefer to
have all related postings explicitly forwarded only through the public
forum(s).

> I drop netbsd-bugs from the cc list but leave it in the envelope.

Please don't ever override my reply-to: header though (unless maybe it's
just to change the forum from being public to private) -- I set it
explicitly to the list (and GNATS in this case) on purpose.  I do not
want to get duplicates (as I did in this case).

Dropping netbsd-bugs in this case drops the public forum through which
people commonly monitor the progress of GNATS PRs.  It's a convenience,
to be sure, but a very valuable one.  Had I configured GNATS for NetBSD
I'd have made netbsd-bugs a moderated list and forwarded all replies
sent to GNATS back out to netbsd-bugs (and perhaps even made all change
notices go there too) (i.e. made netbsd-bugs a write-only distribution
list for PR postings and updates).  The moderator could be /dev/null too
(though that might be a bit harsh).

> | (This patch also includes my "ALLOW_HOSTALIASES" patch which allows you
> | to permanently disable support for the HOSTALIASES env var; as well as a
> | few minor documentation tweaks.)
> 
> That pertty much guarantees that it won't be applied, because no one is
> likely to do the work of seperating out your changes, and they should
> be committed seperately.

Oh well.  I don't really care either way and I don't have time to
separate out diffs.  I'll run the "cvs diff" to show what I've done to
my release -- you can take what you want from that.  If I'd have
committed and tagged the changes separately in my repository then I
could provide separate diffs, but unfortunately that's not the way I've
been doing things so all I've got are amassed diffs of all my changes.
In this case I was able to simply show the changes to the files from
just the one directory since as far as I remember they're all contained
in that one place.  Pretend it's the good old days pre-CVS, pre-Patch,
and I'm just some random user who submits a big hunk of diffs and be
happy if I offer at least some documentation and rationale for my
changes.  It's "your" job as the maintainer to select from my changes
those which "you" feel are applicable for the general release and to
rewrite them as necessary.

> In any case, you provide no compelling argument for why
> DEBUG should be wholesale replaced with RESOLVDEBUG. I will
> accept that such arguments exist, but really, they should
> be made, not presumed.

I thought your original PR made it abundantly clear that DEBUG has a
different meaning in the general NetBSD source tree from whatever
#define might be used to enable support for run-time user-level
debugging in the resolver library.  However you expressed some confusion
over which way you thought would be best to fix the disparity.

My reply was to simply point out that using the same flag/#define for
different purposes, especially if it's magically renamed in the
alternative you proposed, is very misleading and prone to error, and
that contrary to your claim a change of the "#ifdef DEBUG" lines will
not overly complicate the merging (importing) of future resolver source
releases.  I provided my diffs as simply a reference to where I'd found
lines which needed changing.

Note also that the resolver debug code should probably always be
available by default (it's more or less documented as being always
available in several places).  However 'DEBUG' is, as I understand it,
not really supposed to be on by default in the NetBSD tree.  The best
way to accomplish this in a lucid way is to use a separate manifest
constant to enable (or conversely disable) the ressolver runtime
user-level debug code.

Indeed the only reason for being able to turn off the resolver
user-level debugging seems to be for the relatively rare scenarios where
the resolver library is being built for some embedded or similar
application with extremely limited system resources available to it.

The fact that the vendor sources used the lame naming convention of a
simple un-qualified "DEBUG" flag for a special purpose configuration
item is unfortunate, but not terribly unexpected in general.

The only potential problem I forsee in the proposal as I made it is that
if future vendor updates add new "#ifdef DEBUG" code whomever does the
import will have to check that these are also caught and converted if
necessary.  To this end a helper script to do the import preparation (is
there a bind2netbsd.sh or libresolv2netbsd.sh anywhwere?) could allert
the developer doing the import if any new unconverted "#ifdef DEBUG"s
appear anywhere.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>