Python cryptography, Rust, and Gentoo [LWN.net]

Python cryptography, Rust, and Gentoo

Posted Feb 11, 2021 19:57 UTC (Thu) by glaubitz (subscriber, #96452)
In reply to: Python cryptography, Rust, and Gentoo by rgmoore
Parent article: Python cryptography, Rust, and Gentoo

> That leads to the perception that the language as a whole is developing at a breakneck pace, even though it has a good history of preserving backward compatibility.

It may have backward compatibility, but the main problem is that many upstream projects adopt new language feature rather quickly which means that distributions with longer release cycles such as Debian, RHEL or SLE will have to backport new versions of the Rust compiler when updating packages like Firefox.

I have not observed this particular problem with C/C++ code while maintaining packages for an LTS distribution.

to post comments

Python cryptography, Rust, and Gentoo

Posted Feb 11, 2021 21:01 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

Eh, the "core" libraries that "everyone" depends on tends to keep the MSRV (minimum suitable Rust version) pretty low, or at least documented. Sure, things get bumped occasionally, not that even that pace is suitable for LTS distro cadences, but it isn't a mad rush to use the latest-and-greatest for the entire ecosystem.

Python cryptography, Rust, and Gentoo

Posted Feb 12, 2021 4:54 UTC (Fri) by plugwash (subscriber, #29694) [Link] (2 responses)

The reality in Debian is that due to the huge number of security holes that web browsers acrete and the fact that even the LTS release cycles of firefox are much shorter than those of a stable release they are practically forced to upgrade to new release series of firefox within a stable release.

Before firefox/thunderbird started using rust, this wasn't a huge problem, the firefox package could be updated largely independently of everything else. Nowadays though, a new release series of firefox basically means a new release of rustc.

And that breaks things. Sure the rustc developers have defined a stable subset, but a bunch of crates depend on less stable features. Some of this through the officially endorsed "feature gates" mechanism, others through a certain flag that is not supposed to be used by user code but is anyway that lets you use "nightly" features on a stable compiler.

Python cryptography, Rust, and Gentoo

Posted Feb 12, 2021 13:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Some of this through the officially endorsed "feature gates" mechanism, others through a certain flag that is not supposed to be used by user code but is anyway that lets you use "nightly" features on a stable compiler.

Feature gates can only be opened on a nightly compiler. The stable compiler does not let you use them (unless you masquerade as the stdlib with some internal flags, but then you're in a "you get to keep both pieces" situation anyways).

What you're probably actually seeing is the crates using the newer language/stdlib features of *stable* rust releases.

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 8:56 UTC (Mon) by glaubitz (subscriber, #96452) [Link]

> What you're probably actually seeing is the crates using the newer language/stdlib features of *stable* rust releases.

I'm pretty sure I have seen crates that required Rust nightly in the past.

Building rustfmt is one of such cases: https://github.com/rust-lang/rustfmt#installing-from-source