Frederick Bruckman writes:
> I consider this a bug in ftp. On a redirect, the file fetched should
> be saved as the requested name. What if the redirect was for a valid
> tar.gz archive? Then it could get saved to a different file name where
> the subsequent make targets would never find it. Even in the case
> where it's only a stupid error message, at least the behavior would be
> consistent with the non-redirect case.
> 
> If there are good reasons for ftp to behave this way, then perhaps the
> checksum target could be modified to do the right thing when the tar
> file doesn't exist.

This is a tricky issue; when you select a page in a browser that gets
redirected and you save that page, the saved name is usually the name
of the new page.

I'm not sure how other command-line http retrieval tools work determine
which name to save a redirected file as; do you have any experience
here?

In any case, using `ftp -o somefile URL' should always save the output
to somefile, even if URL is redirected. (At least, my testing with
the -current ftp reveals this). If the pkgsrc stuff uses -o and then
checks the generated file, then I can't see what the problem is.