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>