On Wed, Apr 12, 2023 at 4:58 AM Theodore Ts'o <tytso@xxxxxxx> wrote: > > Something that would perhaps be useful is to document (a) what > versions of Rust is available for various distributions, or pointers > to how to get that information for various distributions. For > example, you can get that information from Debian using [1]. It > appears that Fedora isn't distributing rustc at *all*, at least > according to [2], so apparently for Fedora people will need to install > it from source. As far as I understand, Fedora is actually one of the distributions that provide a very up-to-date Rust toolchain (the latest) and can be installed via `dnf` [1][2]. Cc'ing Josh Stone who maintains the toolchain in Fedora, just in case there is something I am missing that the webpage may be referring to. [1] https://packages.fedoraproject.org/pkgs/rust/rust/ [2] https://developer.fedoraproject.org/tech/languages/rust/rust-installation.html > The other thing that would be worth documenting is (b) something about > what versions of Rust people have actually tested. The comments at > [3] are quite scary, since per [4], the minimum version of Rustc > supported is 1.62.0 --- and per [3], **only** Rust 1.62.0 is > supported, since we use unstable Rust features. The one that we test, for the moment, is the minimum one (since it is the "only" one) -- I will make it more clear in the webpage. > But for example, with Debian, Debian stable is shipping Rust 1.48.0, > and Debian testing (which is currently in "hard freeze" so it can be > released as Debian stable this summer) is shipping Rustc 1.63.0. > > Since I use Debian testing, the question which is foremost in my mind > is whether I can expect to have things work if I use the > distro-provided 1.63.0 rustc, or is this really a case of "it's not > Rust 1.62.0, so good luck to you"? Distro versions should be fine (as in: it is not an issue of "official prebuilt images" vs. "distro binaries"). But short-term you likely need to match the numbered version (or perform small changes in the kernel side when needed). So, in practice, the easiest route is to use the binaries provided by Rust itself (via `rustup` or standalone installers). We could also provide them at kernel.org like for other toolchains if that helps. So if distributions want to start using Rust code in their kernels right now (i.e. before we can declare a proper minimum) with their own `rustc` package, then one approach they can use is to provide an extra `rustc-kernel` package matching the version required by the kernel (or to change the kernel side a bit to make it compile). We could, in principle, attempt to support several versions in the kernel side, but given the upstreaming of the first Rust modules is still going on (and the abstractions they depend on), we still have some time. Moreover, the first Rust modules may not be needed by most distributions: what is being upstreamed is the Android Binder driver, the Asahi GPU driver and the NVMe driver so far. So it is up to distributions to decide whether they need to use one of those modules early on, and if that is the case and they need to do so before we can declare a minimum, then I think it is reasonable to ask them to match the version. Some particular users, e.g. Android, as far as I understand, they are OK with matching the version for the time being. In summary, the issue is that the minimum version we will eventually support is "in the future". > If the goal is accelerate adoption of Rustc, and calm people's fears > vis-a-vis using Rust, it's not enough to say, "why don't you use the > distribution-provided version or Rust"? It would be helpful if those > Rust pioneers can share what versions of Rust they have tested > against, especially for those commonly used distributions, such as > Debian, and give us a report whether we should expect things to work, > so we can ignore the scary warning from the build system that we're > using an unsupported version of Rust, and if it breaks, we get to keep > both pieces. Definitely -- we should be testing distro-versions in CI as soon as it is (reasonably) possible. We could even do so already for those distributions that track the latest version, but then it means we will be upgrading more often (every 6 weeks) in the kernel side. There would still be small windows where it may not work depending on how the schedules match, though (but distros could keep a `rustc-old` for some days until it matches again, for instance). > Fedora, if someone could build their own unofficial packages, until we > can convince Red Hat to start shipping -their own supported Rust > compilers, that might be a great way of bridging that gap. I think all major distributions already ship Rust. From a quick look: Fedora (1.68.2), Gentoo (1.68.2), Arch (1.68.2), openSUSE (1.68.0 for the rolling one), Ubuntu (1.67.1 for 23.04), Debian (1.63.0 this summer), Red Hat (1.62.1 in 9.1)... As mentioned above, if kernel maintainers are happy with more frequent upgrades (i.e. tracking the latest release), it would at least be easier for those in distributions that track the latest Rust release -- I would like to do that, in fact, if nobody opposes, since our idea is to anyhow upgrade the compiler required in the kernel until we hit the minimum. What do you think? Cheers, Miguel
