On 01/22/2018 04:22 PM, Aleksa Sarai wrote:
I'm not sure we're understanding each other here -- my point was that the *only* Rust project which has this policy for compiling new versions is the Rust compiler. No other Rust project requires this. That's what I meant by "exception, not the rule". So I agree with what you wrote, but it doesn't have much to do with what I was trying to say, which is that the following quote ...
So, you say it's guaranteed that only the Rust compiler will only ever use particular code that will be deprecated in release N+1 or only available in release N-1? I did build test it myself. I tried building Rust 1.22 with Rust 1.20 which failed with actual compiler errors, not just a warning that I have to use the proper version. And I think it's absolutely not unlikely that Rust project X will run into such a problem as well. What keeps Rust project X from using certain language features that were only recently added or removed? The problem with Rust is simply the lack of stabilization. It's absolutely insane that they think it's ok to break compatibility in minor versions and it blows my mind that so many people find that acceptable. Rust upstream lives in a universe where they think that distributions are an outdated concept. This is why they are shipping their own package manager and consider such breaking changes in minor releases acceptable.
Finally, one problem with Rust that I ran into when working on the Rust compiler code itself is the high volatility of the language and the code. Things that used to build fine with Rust 1.19 would break with 1.20 and so on. From a distribution maintainer's point of view, this can be very tedious and annoying.
... is not accurate for any project other than the Rust compiler (and the reason for the Rust compiler having this requirement is so that they can use new language features in the compiler itself, not because of stability issues with the language). Any other Rust project must be able to build on 1.x and 1.(x+1) with no changes (and the Rust compiler team tests this quite heavily).
What keeps project X from using certain features of Rust? I have seen projects which would only build with Rust Nightly.
So, if SLE wants to update to the next ESR release of Firefox, it will also have to include Rust in the same maintenance request.
We ship a new Go package with most new Docker releases as well (as they usually update the compiler they use every couple of releases, and in the past there were bugs where Docker would break if it was built with the wrong compiler version). This is not really a new thing.
I don't think you always need the latest version of Go for updating Docker. I have worked with both codebases myself and never ran into this issue.
Upstream Go always ensures that golang-go can be built with gcc-go. Rust has mrustc for that, but that one isn't supporting anything beyond x86 at the moment.
Hmmm, this is a policy that appears to have changed after the compiler rewrite to Go. I distinctly remember watching a talk where rsc described that they would require you to have version (n-1) of the compiler in order to build version n -- so that the compiler could take advantage of new language features -- and you would start the bootstrapping at go1.4.
Huh? If it changed after the compiler rewrite in Go, wouldn't that mean that before that the compiler wasn't written in Go which means that you didn't have that problem in the first place?
However, the documentation (and build tools) make no mention of this and just say that you can build everything with go1.4. That's a little bit odd. But yes, I am aware that this is how we (and other distributions) build Go, I was just under the impression that we packaged it this way with go1.5 because "it just worked" and it removed the (n-1) bootstrapping problem.
I stand corrected.
Fair enough. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org