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 02:22:47 +1100
  • Message-id: <20180122152247.4j3x62eni75jj4ky@gordon>
On 2018-01-22, John Paul Adrian Glaubitz <adrian.glaubitz@xxxxxxxx> wrote:
One example for this is the fact that you need exactly version N-1 to
build version N of the Rust compiler. Using a slightly older version or
even version N does not work. Tried that several times.

This is an exception, not the rule, and is something that is solved by
packaging (as it has been solved in openSUSE with the bootstrap
packages).

"@daym Have you tried building Rust with exactly one version before?
Rust version 1.x only supports bootstrapping from version 1.(x-1), not
1.(x-2) or below, and also not 1.x or newer. And can you maybe paste an
error somewhere?"

https://github.com/rust-lang/rust/issues/45593#issuecomment-340187339

You also realize this when you try building rustc from source. When you
build 1.23, it downloads 1.22 and so on.

Furthermore, keeping Firefox up to date already puts requirements on
the Rust version. I can't find the mailing list thread at the moment,
but one of Debian's Rust maintainers who also works upstream at Mozilla
has said that Rust always has to be updated as well when you want
to update Firefox. This is very problematic for LTS distributions when
they are shipping Firefox ESR which is going to introduce a Rust
dependency with the next ESR release which will be version 60.

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

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

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.

There are several other compilers that have this requirement
(Go does for example -- though to be honest we ignore it when packaging
for the most part).

That's not true. Golang-go can be built using gcc-go which can be bootstrapped
purely from C. In fact, the Golang-Go compiler is currrently built using
gcc-go
in Debian.

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.

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.

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