Sorry, EPEL policy does not allow conflicting with RHEL packages:
https://docs.fedoraproject.org/en-US/epel/epel-policy/#policy_for_conflicting_packages

RHEL 8.8 has rust-1.66.1, while CentOS Stream 8 currently has 1.69 (bug 2191741), and we're planning to update to 1.71 (bug 2191740) in time for RHEL 8.9.

While I can appreciate the policy to not allow conflicting (i.e. replacing/updating) packages in EPEL, what is the path forward to get an updated rust compiler in EL8 (or EL9 for that matter) so that software that needs a version of rust that is newer than what is in EL8 can be built for EL8 (or again, EL9 as this issue may apply there)?

(In reply to Brian J. Murrell from comment #2)
> what is the path forward to get an updated rust compiler in EL8 (or EL9 for that matter)

It is still the plan to keep rebasing Rust in RHEL, but that's released on the y-stream schedule. So beyond what I wrote before, RHEL 9.4 and 8.10 shipped Rust 1.75; then 9.5 and 8.10-z shipped Rust 1.79. We're past any more 8.y releases, but still keeping it in sync in z-stream at the same time as later RHEL. This spring we're planning to have Rust 1.84 in RHEL 9.6, with 8.10-z again keeping up.

(More generally, if it were a package not getting rebases in RHEL, you could add a "compat"-style package with a newer version.)

Josh,

Thank-you for taking the time to answer my question.

So, it's great news that the plan is to continue to rebase rust in RHEL and getting to 1.84 by spring is also good news.  But my concern is the lag/latency.  While 1.84 would be great right now, as there is software out in the wild that needs that recent a release of rust, I wonder how suitable 1.84 is going to be in a few months when all of the software that wants 1.83-84 now will want even newer by then.

Is there no way to get the latency down so that we can see more relevant releases sooner?

This kind of latency for a well established compiler like gcc might be workable for something moving as fast as rust is, constantly being many months behind in releases means that there is at least some amount of software out that will never build on RHEL.

I don't think this is as big a problem as you think it is.

I'm keeping track which Rust crate updates from Fedora / EPEL 10 cannot be merged to EPEL 9 due to the lagging Rust compiler version:
https://hackmd.io/@decathorpe/FedoraRustSIG#EPEL-9

Most of these (rkyv, ptr_meta, bytecheck, rend) are interconnected from one project that bumped their MSRV *really far ahead* with the rkyv 0.8 release, which was rather unusual, and I doubt that it will happen again to this degree.

Another chunk is cargo and its library dependencies, which bump their required Rust compiler version frequently, as well. Unless you intend to build a newer version of cargo with an older version of the Rust compiler, that shouldn't be a problem either.

That leaves only four other random crates with MSRV > 1.79 - for one of them I filed an issue upstream and it turned out that the bump was unintentional. For the other three, it should be possible to depend on an older compatible version that has a lower MSRV.

So looking at all ~1900 Rust packages in EPEL 9, I see no "real" problems with lagging Rust compiler versions.

(Of course, this doesn't take into account applications like uv or ruff which *could* be imported to EPEL 9, but which aren't, because they too bump their MSRV frequently. Dealing with this will be much easier in EPEL 10, I hope, due to the different branching model.)

The package that I am running into a problem with is https://src.fedoraproject.org/rpms/vaultwarden which is the Fedora (and EPEL-9, and I'd like to see EPEL-8) packaging for https://github.com/dani-garcia/vaultwarden/ recently released 1.33.0 which included the following changes:

https://github.com/dani-garcia/vaultwarden/compare/1.32.7...1.33.0

I'm not at all a rust developer but I think this is the commit causing problems:

https://github.com/dani-garcia/vaultwarden/commit/16b6d2a71edc3f375346ffe347ec88355917aba0

Or am I misunderstanding this altogether in my ignorance of the rust ecosystem?

Yes - in vaultwarden, it looks like they often bump the minimum supported Rust very aggressively, because they're using features that are only stabilized in the most recent version of Rust (like in the commit you linked).
There doesn't seem to be a good reason for that other than "we want to use this feature to refactor something". Maybe filing an issue with vaultwarden asking them to hold off bumping their Rust compiler dependency so aggressively could work? I don't know.

Most projects have a more restrictive policy here, like "we support the last 6 Rust versions" or sometimes even "we need to support whatever debian stable ships". Projects like vaultwarden that basically require "always latest stable" are quite rare (and annoying to deal with).