Update is happening even if user has a tool and that tool is missing #1486
Comments
|
We need to block nightly on RLS etc. again if rustup cannot prevent uninstall of manually added components. (cc @rust-lang-nursery/infra) (P.S. we need to sync the team members between the two orgs...) |
|
The generated manifests when rls is missing are wrong. The rustup behavior was changed in #1419 to handle removed components (when the docs for some tier 2 platforms were removed and users weren't able to update), but the old behavior is still present when the component is marked as Currently there is no mention of rls in the nightly manifest at all. The easiest way to fix is to keep rls in the manifest but mark it as unavailable, and this doesn't require any rustup update. |
…excrichton Include missing tools in the manifest and mark them as unavailable This PR changes the `build-manifest` tool to always include the missing components in the manifest, marking them as `available = false`. This blocks rustup from updating to a different nightly if the component is installed. The code builds and _should_ be correct, but I don't know a way to test the changes locally. r? @alexcrichton cc @kennytm rust-lang/rustup#1486
|
This should be fixed with @pietroalbini's PR |
|
When will that fix propagate out? The 2018-08-29 nightly still upgraded and warned about missing rls-preview and clippy-preview components. |
|
It should have worked today :-( |
|
In today's manifest, rls and Clippy have |
|
Nope, experimented with this for a bit locally, and it's still a manifest problem. While the components themselves are [[pkg.rust.target.x86_64-unknown-linux-gnu.components]]
pkg = "clippy-preview"
target = "x86_64-unknown-linux-gnu"
The error messages are still really bad, but at least we don't upgrade people with components installed. I'll look into sending a PR to rustc soon to tweak manifest generation again. |
Fix manifests for broken tools: take 2 This is a follow up of #53715, to avoid stripping unavailable components from the extensions list. This time I also figured out how to test the changes, so the produced manifest is correct. Along with the fix I added a README with instructions on how to test the tool, and a new `BUILD_MANIFEST_DISABLE_SIGNING` env var to avoid dealing with gpg while testing the tool. I chose an env var instead of a flag because it's more difficult to have it slip in by accident on CI, and there is also another protection that panics if that env var is set on CI, just to be sure we don't release unsigned artifacts. r? @alexcrichton cc rust-lang/rustup#1486
|
Ok, this should be fixed now. |
|
Awesome, thank you! |
This should require
--force.cc rust-lang/rls#641
The text was updated successfully, but these errors were encountered: