Mailinglist Archive: opensuse-packaging (94 mails)

< Previous Next >
Re: [opensuse-packaging] On how to improve Rust packaging experience for suse
On Tue, Nov 19, 2019 at 6:51 AM John Paul Adrian Glaubitz
<adrian.glaubitz@xxxxxxxx> wrote:

Hi!

On 11/19/19 12:58 AM, William Brown wrote:
Rust as a language has a very aggressive release cycle compared to what we
expect on a platform like SUSE - 6 weeks
(https://github.com/rust-lang/rust/blob/master/RELEASES.md). In each cycle
Rust releases new features, and despite the core language being "stable"
and safe (which is great!) new features tend to be used very rapidly by
library authors. For example the release from Version 1.34.0 (2019-04-11)
contains convert::TryFrom, which is now in use by a large number of
libraries.

Is that really that common? I have had a lot of interaction with Rust upstream
through Debian and I was always told it's normally only the Rust compiler
itself
which uses new features in its own code which is why it always needs to be
built
with either its own version or the previous version, older or newer versions
usually
break.


Unfortunately, the cake is a lie. The Rust community does not have a
culture of conservatism. To be fair, they have not yet been burned by
using the newest features as soon as they become available. But this
is why Fedora is on the Rust compiler update treadmill.

It sometimes happens that 3rd party Rust software projects are affected by it
like
you say, but I have observed that only occasionally unless the Rust compiler
is
really old. But maybe the situation is worse when using SLE due its long-term
character.


The situation is definitely aggravated in RHEL and SLE, since it's
fairly difficult to update the compiler in those distributions
(because of the difficulty of the update submission and approval
process, not because of a technical problem).

However, generally I think that Rust should slow down with frequent
incompatible
changes to the language itself as this prevents independent compiler
implementations
to keep up. mrustc is currently compatible with Rust 1.29.0 and from GCC
upstream
I have heard that the frequent changes are the main blocker for adopting a
Rust
frontend in GCC.


The Rust community needs to get burned a few times first. But I think
we're a long ways away from that happening. The Rust compiler
developers are smart guys, but they don't understand that
bootstrapping Rust is not supposed to be so hard. It doesn't help that
Rust upstream doesn't care much about concerns from distributions and
downstream developers.




--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups