Better integration with rustfmt and clippy is definitely welcome. I think the profile approach to define what gets installed can probably be helpful. Having the stubs sounds like a nice UX improvement.
In terms of tool breakage: I tend to think that the CI should just (I’m aware the “just” here might have deep costs that are hidden to me) not put out an update when any of the tools is broken. If Firefox manages this stuff, why can’t Rust? Back things out that break the tools, or hold back updates until all the tools are fixed. Having nightlies that don’t have some of the tools is a pain in the ass, even if I don’t use nightly most of the time (because now I have to pin my nightly in CI to make sure it has clippy).
As for diskspace/bandwidth: it may not be that much, but I’ve found that having to update my toolchain is definitely an unwelcome break in my process, especially when I have to use nightly (usually in order to use clippy). I don’t know how the size of rls c.s. compare to rustc and std, but I just want to make the point that pulling in stuff that won’t get used is still not a great idea. (Alternatively, could the stub [offer to] auto-install the first time it gets used? That would be a pretty nice experience.)
I really like @JeanMertz’s suggestion of having toolchains be more orthogonal to tools: that is, if you install clippy on stable, it should also be there on nightly (and vice versa, modulo availability).
As another Gentoo maintainer (who was on the other side of the debate @lu_zero mentioned), I’ve found that the Rust project tends to treat the Rust distribution as something of a monolith. This might make sense if you look through the lens of rustup, which is understandably a priority as likely most users use Rust this way. But some of the changes over the past year have made the tools less easily distributable as separate components; for Cargo, the Cargo lockfile (which would enable us to have a more-faithful build of what upstream distributes) has moved into the rustc repo IIRC, and Cargo’s git version numbers now no longer relate to the version numbers in Cargo’s UI (which is now the rustc version). (Our full discussion can be read here, if anyone’s interested.) I’ve accordingly made the Gentoo distribution more monolithic in order to save my own sanity – I don’t want to spend my time fighting against the tide – but, especially when you’re compiling from source, there are definitely downsides to the monolith approach.
Better modularity in rustbuild would also help here.
(Also in terms of distributed components, can someone please clarify the documentation situation?)
In general, it has felt like there’s not a clear contact for packagers. Even if the distributions are understandably not the project’s first focus, it would be nice if there was a bit more clarity on who is responsible for these kinds of issues.
(This is something I am painfully familiar with from working with Ember CLI in my day job.) I’m happy to pitch in on what’s needed to make that happen if someone points me in the right direction.