Mailinglist Archive: opensuse-factory (745 mails)

< Previous Next >
Re: [opensuse-factory] Tumbleweed - Review of the week 2018/03
  • From: Aleksa Sarai <asarai@xxxxxxx>
  • Date: Mon, 22 Jan 2018 12:09:46 +1100
  • Message-id: <20180122010946.tmimxzgurije5irw@gordon>
On 2018-01-21, John Paul Adrian Glaubitz <adrian.glaubitz@xxxxxxxx> wrote:
This is actually a huge change as librsvg is a core library with a large
number of reverse dependencies now partially written in a programming
language with limited architecture support.

Yes, I agree this is a problem -- maybe we should keep around an old
version of librsvg purely for "tier 2" architecture support?

Aren't arm64, ppc64el and s390x tier 1 architectures in SLE?

I meant "tier 2" from the PoV of Rust, not SLE.

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.

This is not correct for the *stable* compiler, because they provide
stability guarantees for it and they do regular "crater runs" (rebuild
every crate in the Rust ecosystem, checking if there are any new errors
or warnings). I find it quite improbable that you hit this issue in the
*stable* compiler (and if you did, it was a bug, and I hope you reported
it). The *unstable* compiler (by it's nature) doesn't provide any such

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

Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
< Previous Next >
This Thread