Re: pkg/36603 (pkgsrc "make checksum" even more broken than I suspected)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/36603 (pkgsrc "make checksum" even more broken than I 
suspected) 
Date: Fri, 31 Aug 2007 18:34:11 +0700

     Date:        Fri, 24 Aug 2007 03:19:51 +0000 (UTC)
     From:        jlam%NetBSD.org@localhost
     Message-ID:  <20070824031951.9334E63B898%narn.NetBSD.org@localhost>
 
   | Please let me know if revision 1.8 of pkgsrc/mk/checksum/checksum.mk fixes
   | the problem that you note in your PR.
 
 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...)
 
 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).
 
 That is, I keep a set of distfiles for (almost) everything (only licensing
 issues affect a few), and I verify the checksums of the distfiles (at least)
 once every week - I want to do that regardless of whether I happen to
 have recently built (and not cleaned) one of the packages - given enough
 space (which I almost have, but probably not quite) I'd never clean
 anything (until there's a version upgrade of course .. and if the Makefiles
 for the pkg could be trusted, even then a clean shouldn't really be needed,
 for many upgrades, many of the .o files (.a etc files) from the last version
 are probably identical to the new one, and could be retained - but I am not
 really willing to trust random pkg Makefiles (that is, from within the
 distfiles) to handle this correctly).
 
 Even if a package is in the process of building, right now, I want to be
 able to "make checksum" and get results - the weekly checksum of everything
 script is run from cron, when it runs, sometimes, packages could be building
 (particularly when something big, like openoffice or kde has just been
 upgraded) - I don't want to miss getting checksum reports in the log file
 just because something happened to not be clean (actually extracted) at
 the time.
 
 The worst that can happen is a false "error" report if the distfile is
 half fetched when the "make checksum" runs, that's OK, I always verify
 that the checksum is 
 
 There's no reason at all this shouldn't work, "make checksum" should touch
 nothing (as in alter nothing) and doesn't care who else might be using
 the distfile, or anything else related to the package - just as long as
 it can get at the distinfo file and the distfile(s) to read.
 
 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).
 
   | 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).
 
 kre