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) _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
