-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Message following "Updating binary package" doesn't make sense #697
Comments
I did not write the updating support. But I vaguely think it may be triggered in the case that the binary has been cached locally but it is being also checked remotely? But overall, if it was broken for so longer and nobody noticed/complained them it may actually be find to remove the support. The usecase of having things locally and updating is one I handle by |
I prefer not re-downloading what I already have; especially when I'm on slow limited connection. That's why I symlink I'm okay with skipping the remote check by default, if the local file already exists. But as long as packages can be re-published under the same version number, there should be some way to force this cheap check (curl -z aka If-Modified-Since). |
Yes, I've often wanted this, just not had time to write tests for it.
👌
Right. As previously discussed, we tried to get away from that. Or at least it should be so rare that it should not need to be supported locally with re-fetching. |
Before af24915 the message was:
the script was broken, and the message could not be trusted, because it didn't actually check the package URL.
After af24915 it is:
Now it actually checks the URL, but then says it's not available. I'd assume curl should succeed with HTTP status 304 Not Modified, but it appears to work differently.
The text was updated successfully, but these errors were encountered: