[FFe] Versioned packages for Rust toolchain

[Simon Chopin]

Hi,

In the rustc MIR at
https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957932 it was proposed
that the Rust toolchain start using versioned source packages to allow multiple
versions in the archive at the same time. The issue was discussed in-person
during the recent sprint, and consensus was that this would be a good idea
going forward to minimize the risks associated with updating the toolchain in
stable releases, which as before will be necessary for Firefox support.

However, the question arises of what to do with the current src:rustc package
in Jammy. I see two paths forward:

1/ We could rename src:rustc into rustc-1.58, adding the proper suffixes to its
binaries, and introduce a new src:rustc-defaults package setting up symlinks to
the new rust*-1.58 binaries. This would be needed if we'd expect the whole Rust
ecosystem to move on to the newer toolchains as they are uploaded to the LTS.
Similar work would probably be needed for src:cargo.
I'm assuming this would require an FFe, as the potential for breakage in the archive
seems quite high.

2/ We could do *nothing*. We'd need to update the packaging of Firefox to deal
with versioned binaries for rustc and cargo when the time comes, and the rest
of the Rust ecosystem in the archive would remain tied to the 1.58.1 version of
rustc. The (other?) downside is the lack of consistency within the Jammy
release, where we'll have one version of rustc that's not explicitly versioned.

Writing this all down makes me lean more towards 2/ as the proper solution
here. However, I think this should be discussed in the open, and would benefit
from the Release Team's input.

TIA!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Olivier Tilloy (osomon)]

Note that in jammy, with bug #1962021 firefox isn't tied to rustc/cargo any longer, as it becomes a simple wrapper that installs the snap (and the snap itself uses upstream builds of rustc and cargo).

Thunderbird still depends on rustc and cargo in the archive.

In any case, both options look valid to me. Mozilla products are rather tightly coupled to a given version of rustc/cargo anyway (see https://hg.mozilla.org/mozilla-central/file/tip/docs/writing-rust-code/update-policy.md), so having to update their packaging to specify versioned binary deps sounds fine.

[Sebastien Bacher (seb128)]

Solution 1) feels a bit cleaner because there is no special casing of one version but at the same time it's not likely that we will be changing -defaults in a SRU so option 2) is less work and equivalent. Package that want to use a newer serie will have to target it specifically

+1 from me for option 2)

[Steve Langasek (vorlon)]

I am broadly uncomfortable with this as an FFe because it sounds like the direction is still being settled out and the rationale is not clear for jammy given that firefox does not appear to need in-archive updates of rustc anymore. Further, I don't think whether or not you used versioned source packages is related to status in main - we have the same expectation of ongoing buildability of reverse-dependencies for packages in universe when doing SRUs.

My preference is to nack this as any sort of FFe. The door is left open for option 2, as introducing additional versioned source packages to jammy in SRU as needed, which would only happen with appropriate justification during the SRU process.

[Simon Chopin (schopin)]

Alright, the consensus seems to be for option (2). Less work for me :-).

As for future SRUs for newer versions, thunderbird seems regularly upgraded in stable releases and will need regular rustc bumps.

Closing this as Invalid, feel free to correct the status if that's not the right one.

[Seth Arnold (seth-arnold)]

I can really appreciate the appeal of a "do nothing today" solution but I'm worried about how much work, and unknown surprises, await us on our *first* update in the future.

At some point, we'll have a security issue in a rust program that can only be solved in coordination with a toolchain update, and we'll need to learn what needs to be done, what parts need updating, etc, while under duress.

Will our unfamiliarity with this process provide us with an insurmountable stumbling block in the future, one that risks our users or our reputation?

Thanks