Skip to content
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

Open
lightmare opened this issue Sep 3, 2019 · 3 comments
Open

Message following "Updating binary package" doesn't make sense #697

lightmare opened this issue Sep 3, 2019 · 3 comments

Comments

@lightmare
Copy link
Collaborator

Before af24915 the message was:

* Updating binary package linux-x86_64/gdal/2.4.1.tar.gz...
curl: no URL specified!
curl: try 'curl --help' or 'curl --manual' for more information
* Binary package is still up to date

the script was broken, and the message could not be trusted, because it didn't actually check the package URL.

After af24915 it is:

* Updating binary package linux-x86_64/gdal/2.4.1.tar.gz...
* Binary not available yet for linux-x86_64/gdal/2.4.1.tar.gz

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.

@springmeyer
Copy link
Contributor

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 rm -rf mason_packages/ && mason install ...

@lightmare
Copy link
Collaborator Author

I prefer not re-downloading what I already have; especially when I'm on slow limited connection. That's why I symlink mason_packages/.binaries to ~/.cache/mapbox/mason.binaries (which mason should be using by default, IMO, but that's a different discussion).

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).

@springmeyer
Copy link
Contributor

which mason should be using by default, IMO, but that's a different discussion).

Yes, I've often wanted this, just not had time to write tests for it.

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).

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.

@mapbox mapbox deleted a comment from polospb1 Jun 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants