Incorrect downloads still marked as completed

[joe@…]

When macports fails to download a file correctly (but does receive something, eg an html file due to a misconfigured proxy), the download is still marked as completed and does not get re-attempted, see log section:

--->  Dependencies to be installed: py27-distribute py27-numpy atlas gcc44 gcc_select gzip fftw-3 py27-nose
DEBUG: Starting logging for py27-distribute
DEBUG: Executing org.macports.main (py27-distribute)
DEBUG: Skipping completed org.macports.fetch (py27-distribute)
--->  Verifying checksum(s) for py27-distribute
DEBUG: checksum phase started at Thu Jun  2 09:31:26 BST 2011
DEBUG: Executing org.macports.checksum (py27-distribute)
--->  Checksumming distribute-0.6.18.tar.gz
Error: Checksum (md5) mismatch for distribute-0.6.18.tar.gz
Portfile checksum: distribute-0.6.18.tar.gz md5 9c9d7489136fe8b57950dd827c979fff
Distfile checksum: distribute-0.6.18.tar.gz md5 e5bc1e56c435da931fc3121aaa130397

Because of this, subsequent attempts to install this file assume the download has already completed and skip direct to the checksum phase which will obviously fail.

Similarly deleting the file still assumes the download is successful, so the checksum phase again fails this time because the file is not present at all.

The download *should* never be considered as completed until the checksum has been verified! If a download fails, subsequent installation attempts should delete the corrupted file and try again to download (allowing the user to correct the problem in between).

There is no obvious way to force a redownload of the file.

[ryandesign (Ryan Carsten Schmidt)]

Replying to joe@…:

There is no obvious way to force a redownload of the file.

"sudo port clean --all <portname>" is the way you're meant to deal with this.

[jmroot (Joshua Root)]

Fetch and checksum are separate phases. Fetch did download something, so it's complete. The build phase is also marked as complete even if the code is not built correctly, as long as make exits with status 0.

Changing the fundamental way targets work would be a really big job and it's not clear that it's even a good idea. The design decisions in port(1) are geared towards allowing you to diagnose what went wrong, rather than glossing over the fact that anything did. A nice user-friendly automatic "clean up and try again" behaviour is the domain of some other tool, like Pallet or the proposed interactive command-line front end.