[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/36603 (pkgsrc "make checksum" even more broken than I suspected)
The following reply was made to PR pkg/36603; it has been noted by GNATS.
From: "Johnny C. Lam" <jlam%pkgsrc.org@localhost>
Cc: pkgsrc-bugs%netbsd.org@localhost, kre%munnari.OZ.AU@localhost
Subject: Re: pkg/36603 (pkgsrc "make checksum" even more broken than I
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).
> 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
> 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.
-- Johnny Lam <jlam%pkgsrc.org@localhost>
Main Index |
Thread Index |