Mailinglist Archive: opensuse-factory (745 mails)

< Previous Next >
Re: [opensuse-factory] Tumbleweed - Review of the week 2018/03
  • From: Aleksa Sarai <asarai@xxxxxxx>
  • Date: Tue, 23 Jan 2018 22:14:51 +1100
  • Message-id: <20180123111451.lpieuatgvc5cyobe@gordon>
On 2018-01-22, John Paul Adrian Glaubitz <adrian.glaubitz@xxxxxxxx> 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'll be honest that I am not sure of the reason why the Rust compiler is
special in this sense. However, from the discussions I've had with folks
from the Rust community, it's related to the fact that the standard
library is "special" (in the same way that Go's "runtime" and "internal"
libraries are quite special) and it should not be possible for a crate
(that is built on stable) to have the same properties as the Rust
compiler.

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.

As has been discussed in the rest of this thread, Rust has a very
specific stability guarantee which is effectively following:

"Any Rust crate which builds on a stable version of Rust today is
guaranteed to build on a future stable version of Rust tomorrow. If it
does not, it's a bug."

You have given two examples where this was not true:

* The Rust compiler, which as we've discussed is not a "Rust crate".

* A Firefox version which was broken by the removal of some keyword.
From what you describe this sounds like a bug, and a violation of
their stability guarantee. Mistakes happen -- though this one seems to
be quite large to not have been mentioned anywhere else -- and I hope
that you submitted a bug report, because I'm sure that they would've
resolved the problem.

You mention that Go does a lot of testing to avoid regressions, *so does
the Rust community*. They do a "crater run" (rebuild and unit-test of
all crates on crates.io) on a regular cadence during development, when
large features are being considered for merging, and for gating
releases.

If they find an issue they either fix it in the compiler (if it's a
regression) or they go to the project itself and submit a patch (if it's
actually a bug in the project). This is one of the things that is
mentioned in literally every talk about the Rust development process.

If they really did break Firefox, then I would like to see a post-mortem
for why their regular crater runs didn't pick it up. But the right thing
to do in this situation would've been to report a bug, rather than to
conclude that Rust is unstable and move on without telling anyone.

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.

I agree that their attitude toward distributions is a problem (for us
obviously, but also for users IMO). But this is also an attitude that is
shared by a very large number of languages and projects these days.

I cannot help but think that the root cause of this problem is that we
have not done a good job (as distribution developers in general) of
convincing people of the benefits of having a distribution that has a
global view of packaging of a system.

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.

I think us trying to ship projects that use Rust Nightly would be
absolute madness (I also think it's mad to depend on Rust Nightly
features for a "stable" project, but that's a separate topic). However,
we can avoid the nightly problem by not shipping things that depend on
nightly (neither Firefox nor the library that spawned this discussion
depend on Nightly).

However, Rust Nightly != Rust Stable. The "certain features" you refer
to are unstable features that cannot be used if you compile with the
stable compiler.

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.

Not always, but there have been cases (we're talking ~2 years ago) where
a Go upgrade has broken Docker in subtle ways. This was before runc was
a separate project, and they were still using "os/exec" for parts of
container setup (which obviously proved to be a horrible idea, and now
we have the whole nsexec magic that I'm tasked with maintaining upstream).

These days most new Docker releases use a new Go version, and so we
bundle a Go update "just in case" (and usually they do actually use
newer language features).

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?

I meant that the policy they *planned* to have was the whole (n-1)
bootstrap thing, and the *policy* appears to have changed after I looked
into it. If you'd like to see what I mean, you can Google rsc's talks
about the Go compiler rewrite from a few years ago.

--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
< Previous Next >
This Thread