3

Both Ubuntu 22.04 and 24.04 have rustc 1.75, with additional versions up to 1.80 in packages like rustc-1.77. Rust 1.81 is not available from the official repository of any LTS version (only oracular and newer).

Rust 1.80 was released in July 2024, not long after 24.03 itself was released. I would have naively expected the base rustc package to be newer in 24.04, and/or the additional packages in 24.04 to go on until July 2026, but that doesn't seem to be the case.

This situation where one LTS release got new versions of the language multiple times over two years, and the other basically never had any update, is more than a bit confusing. I would like to understand if there's some kind of policy for introducing new versions of rustc in Ubuntu LTS releases, so that I can plan which Rust features to use for software that wants to be buildable on Ubuntu 24.04, and when.

Archisman Panigrahi
  • 40,026
Paolo Bonzini
  • 141
  • 1
    This question is similar to: Why don't the Ubuntu repositories have the latest versions of software?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. – guiverc May 02 '25 at 22:03
  • Don't forget the important date(s) are NOT the release date, but the various freeze dates before that, ie. UI freeze, feature freeze, etc.. before final freeze. – guiverc May 02 '25 at 22:03
  • It Is different because it is specific to Rust, where there are exactly the same versions in the two active LTS releases: one LTS release was updated for two years and the other for three months. I would like to understand if there's some kind of policy so that I can plan which Rust features to use for software that wants to be buildable on Ubuntu 24.04, and when – Paolo Bonzini May 02 '25 at 23:54
  • Just look at what the various freezes and stable release update procedures require... ie. once a release occurs it's stable and SRU procedures must be followed; and that applies to all packages so rust doesn't change. The same applies with freezes; ie. certain things qualify for freeze exceptions which are documented; 24.04 is the 2024-April release; so freezes are history (excluding point release ISO freezes and the few packages involved there) & stable release update rules apply to the whole noble repository. Work currently is a good way thru 26.04 LTS two year cycle – guiverc May 03 '25 at 01:13
  • 2
    @guiverc this may be a complaint phrased as a question, because the Rust project doesn't have LTS-compatible releases. It's evergreen like Chrome with no updates nor security patches after 6 weeks. The wider Rust ecosystem support deteriorates in ~3 months. This means that Ubuntu's stable/LTS versions of Rust appear broken and useless to Rust users. Ubuntu should not package Rust if it can't update it on a 6-week schedule. – Kornel May 03 '25 at 03:20
  • @Kornel Ubuntu is moving towards rust (eg. https://discourse.ubuntu.com/t/migration-to-rust-coreutils-in-25-10/59708) and thus future releases may differ to what exists now (esp. for users of older releases like 24.04 LTS) but development discussions are off-topic here (as packaging of current releases, esp older 24.04 may differ to later releases; many details actually published) – guiverc May 03 '25 at 03:46
  • @Kornel yes the question is definitely both out of the frustration of not being able to understand which versions of Rust will be available in Ubuntu 24.04 and when – Paolo Bonzini May 03 '25 at 07:08
  • @guiverc we are talking past each other. There was definitely work done on Rust packaging after the various freezes in both 22.04 and 24.04, since both include a version that was released in July 2024. My question is whether there is a policy for such post-release updates or is haphazard. – Paolo Bonzini May 03 '25 at 07:18
  • Ubuntu 24.04 LTS released with libstd-rust-1.75 | 1.75.0+dfsg0ubuntu1-0ubuntu7 | noble | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x picking one package, it's been updated to libstd-rust-1.75 | 1.75.0+dfsg0ubuntu1-0ubuntu7.1 | noble-updates | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x which is the same version with security fixes applied to it. Rust on stable releases (currently) has no special rules; updates are on package level & standard SRU rules apply. – guiverc May 03 '25 at 07:55
  • I am talking of packages added after the release, not about the version at freeze time. See https://packages.ubuntu.com/search?keywords=rustc-1.80&searchon=names&suite=all&section=all for an example. If there's no policy and it's all random, then I guess that's an answer. – Paolo Bonzini May 03 '25 at 08:01
  • Once released (as stated), SRU rules apply to the repositories ; policy I mentioned hours ago in prior comment... – guiverc May 03 '25 at 08:08

2 Answers2

2

Once a release is stable and actually released (eg. Ubuntu questing will be released to Ubuntu 25.10), standard SRU policies apply.

Refer https://documentation.ubuntu.com/sru/en/latest/

For new packages refer to the instructions under heading "NEW queue in the SRU context" which states

The SRU policy does not forbid uploading a new source or binary to active releases. But if that happens it needs double approval...

guiverc
  • 33,923
  • This is what was said ~six hours ago (in comment), but with link. – guiverc May 03 '25 at 08:10
  • And it also doesn't explain why Rust was handled in two completely different ways by Canonical in 22.04 (two years of updates post release) and 24.04 (three months). Based on https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases, which I found from the given link and which doesn't have any Rust section, I take it that it's completely unpredictable. – Paolo Bonzini May 03 '25 at 09:38
  • SRU refers to each package independently.. ie. libstd-rust-1.75 I mentioned earlier was updated as a SRU update, but if a NEW upload was made to package libstd-rust-1.81 or something; that is a VERY DIFFERENT matter as its a new package, but is still a SRU but will go thru the NEW QUEUE as per this answer... Community members (a MOTU for example) could volunteer to do this, even if Canonical won't spend resources to do it (the new package would thus be in universe in this example, as per standard policies) – guiverc May 03 '25 at 09:42
  • If not obvious; prior comment was referring to packages in noble or 24.04, given libstd-rust-1.81 does NOT currently exist there... Ubuntu Release/SRU team may also mandate a 24.04 or some other name [minor] name change will be required, I'm using this only as example – guiverc May 03 '25 at 09:49
  • "Community members (a MOTU for example) could volunteer to do this" but Canonical did it in 22.04 and the package is not in universe. My question was whether there is any kind of predictability in what Canonical does. I guess I will accept this answer. – Paolo Bonzini May 03 '25 at 10:24
1

Canonical used to package julia, but they stopped for the same reason and replaced it with the julia snap package. Perhaps the same can be done for rust.

Don't use the official repositories. Instead, use rustup to manage rust versions.

Use the following command to install rustup.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Archisman Panigrahi
  • 40,026
  • 2
    I know how to install rustup. But the software I develop (QEMU) comes from the C world and tries hard to build out of the box with distro packages only. Adding Rust support we want to avoid regressing this aspect. – Paolo Bonzini May 03 '25 at 07:05
  • @PaoloBonzini how about a snap package? That mostly behaves as a distro package – Archisman Panigrahi May 03 '25 at 12:49
  • Until now there has been no need to include third party software (the rustup snap is also downloading third party binaries) in the build, and it would be a regression to do so. – Paolo Bonzini May 03 '25 at 12:55