The following reply was made to PR pkg/36603; it has been noted by GNATS.

From: "Johnny C. Lam" <jlam@pkgsrc.org>
To: gnats-bugs@NetBSD.org
Cc: pkgsrc-bugs@netbsd.org, kre@munnari.OZ.AU
Subject: Re: pkg/36603 (pkgsrc "make checksum" even more broken than I suspected)
Date: Fri, 31 Aug 2007 14:19:30 +0000

 On Fri, Aug 31, 2007 at 12:20:08PM +0000, Robert Elz wrote:
 >  
 >  It fixes it for most purposes, and I suspect it will solve my problem
 >  (that is, allow me to remove the "make clean" immediately before
 >  "make checksum" in my scripts).  Certainly the worst of the problem
 >  should be gone now I believe (make checksum succeeding because it
 >  had earlier failed, and was thus recorded as already performed...)
 
 Okay, this was the main part of the PR that I was concerned about
 fixing, and I'm glad the changes did fix it.
 
 >  But, if I understand the change correctly (and perhaps I don't), I'm not
 >  sure it is perfect yet - that is, even after "make extract" I's like
 >  to be able to check the checksums (without needing to make clean).
 [snip]  
 >  What I'd suggest is to note that there are two different uses of the
 >  checksum target - humans (and scripts) that actually want up to the
 >  second accurate checksum validation, and pkgsrc infrastructure that is
 >  building the package, and just needs to know that the checksum verified
 >  correctly, sometime (to avoid getting either errors, or a bad package,
 >  later).   For pkgsrc, perhaps to avoid the cost of computing a
 >  checksum multiple times, use of a "done" cookie may be OK.  For the
 >  human target, it isn't (in general cookie files are always a bad idea
 >  for human targets, if the human says "make x", then x should be made,
 >  and the only reason to no-op is if x already exists, not just because
 >  some action x was earlier performed).
 
 At the time I committed the fix for this PR, I was thinking about
 splitting the checksum target into a part that is run as part of the
 normal build process, and another that could be run "on-demand" by
 the user.  I think we're  thinking the same thing here.  I committed
 the smaller fix I made because this change was much larger and I wanted
 to get a working fix into pkgsrc first.
 
 I will leave this PR as analyzed for now, and I hope to commit a change
 with your proposed behavior later today, at which point I'll request
 testing and feedback again.
 
 >  
 >    | In general, for infrastructure bugs that are rated "high", I think
 >    | it would be good to post a query on tech-pkg@ as well as submitting the PR
 >  
 >  OK, I'll try to remember that for the future _ I guess I just assumed that
 >  relevant PRs would always be read by appropriate people (even more directly
 >  than random list traffic on any list).
 
 We definitely try, but experience shows that the folks doing pkgsrc
 infrastructure development are almost always reading tech-pkg@, so if
 an infrastructure PR isn't being handled in a timely fashion, a nudge
 there can help attract attention to an overlooked PR.
 
 	Cheers,
 
 	-- Johnny Lam <jlam@pkgsrc.org>