Retry on checksum failures?

[David Evans]

Bryan Blackburn wrote:
>
> In theory, trying other servers on a checksum mismatch makes sense, but
> there are a few areas where this would be really annoying.  Take, for
> example, the texlive_texmf-docs port whose distfile is 255M; for large files
> like that, I'm not sure we'd possibly want to re-download it multiple times.
>
> I can think of a couple ways to improve the fetching: adding a distsize key,
> and making use of HTTP's HEAD.
>
> With distsize, port can check to see if what it downloaded is close to
> what's expected when checksums don't match, and if if it's a really small
> file (eg, HTML error page and not the distfile) try elsewhere.  Of course,
> this still doesn't really fix what happens on either a stealth upgrade or
> corruption.
>
> With using HEAD, port could test first for things like size, maybe even
> checking Last-Modified to try and be smarter about what it may be
> downloading.
>
> In the end, of course, any possible solution will need someone to implement
> it as well...
>
> Perhaps there's another, simpler, solution I'm not thinking about?
>
> Bryan
>
>
>   
That would certainly help and would probably be easier to implement as
the check would
occur while still in the fetch phase and would not necessitate back
tracking to the fetch phase
when an error occurs in the checksum phase.

On the other hand, in the current situation, if the checksum fails then
there's no getting around
the fact that the user will have to fetch again (probably later than
sooner when the
Portfile has been changed) if he really wants the port.  And in
addition, he has to suffer the
frustration of not being able to do anything other than file a bug
report and wait to see what
happens before he can manually retry.  So even with a large file, I
would vote for an immediate
retry with another site.

This assumes however that the case is as it was today.  One site with a
bogus file rather than
the maintainer just forgetting to update the checksums (didn't he test?).

In addition, it would be nice to have a maintainer tool a bit like
distcheck that would iterate
through a ports site list and download and checksum each site to check
for this sort of problem.

It's a real pain to do this manually for a large list.

By the way, a distcheck of gimp2 showed that the file on the offending
site was newer than the Portfile
so either it was slow in syncing to the master GIMP site or it was
changed later.

Dave

[1] http://trac.macports.org/ticket/17057  (missing reference from
previous email)