Update the base image to RockyLinux 10.0

[eshattow]

10.0 adds new architecture riscv64, a per-requisite for building riscv64 releases.

• Update the base image to RockyLinux 10.0

For reasons I do not understand, the riscv64 images for 10.0 do not appear listed as published images on Docker Hub web interface. However, I confirm the riscv64 images are usable in the normal way, as on RISC-V hardware w/ all upstreamed U-Boot firmware, Linux kernel, and Debian 13 Trixie OS:

$ uname -a
Linux hay 6.12.43+deb13-riscv64 #1 SMP Debian 6.12.43-1 (2025-08-27) riscv64 GNU/Linux

$ docker pull rockylinux/rockylinux:10.0-minimal
10.0-minimal: Pulling from rockylinux/rockylinux
79a8196f9f10: Pull complete 
Digest: sha256:734ff5bd7c88c9585b9116fa5d75d0f32a77bdf395d76da12721e75588cd9a50
Status: Downloaded newer image for rockylinux/rockylinux:10.0-minimal
docker.io/rockylinux/rockylinux:10.0-minimal

$ docker run -it --rm rockylinux/rockylinux:10.0-minimal /bin/bash
bash-5.2#

Code-Reviewer Section

The general pull request guidelines can be found here.

Please check each of the following things and check all boxes before accepting a PR.

• The PR has a description, explaining both the problem and the solution.
• The description mentions which forms of testing were done and the testing seems reasonable.
• Every function/class/actor that was touched is reasonably well documented.

For Release-Branches

If this PR is made against a release-branch, please also check the following:

• This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or main if this is the youngest branch)
• There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)

[dlambrig]

I didn't think we are ready to support rocky10. It may be better to modify the script to accept an environment variable to choose the rocky version, that would be defaulted to 9.6.

[xis19]

lgtm

[vishesh]

Don't think we can bump up the version just yet. It may require some approvals for partner teams, definitely some testing, and some changes at some other places. I don't think we should add any special case for riscv unless we are ready to support it.

[dlambrig]

putting the PR on hold until we have an answer of 10.0

[johscheuer]

10.0 adds new architecture riscv64, a per-requisite for building riscv64 releases.

I think this statement is wrong. The Dockerfile where you updated the base image doesn't build anything of FDB and actually requires that pre-compiled binaries exist, either locally or as a release. You probably want to create a new build support image: https://github.com/FoundationDB/fdb-build-support, thought I don't think we have plans to support RockyLinux 10 and risc64, so all of this would probably a community effort so far.

In addition I'm a bit sceptical to use a x.0 version/release as the default version for any production setup.

It may be better to modify the script to accept an environment variable to choose the rocky version, that would be defaulted to 9.6.

I think, given that we have no rsic64 binaries, the benefit of doing that would be quite limited and I would also assume that quite a few things will break either with RockyLinux 10 an/or risc64. This also makes it hard to validate things work since we cannot build those images without the fdb binaries.

[eshattow]

10.0 adds new architecture riscv64, a per-requisite for building riscv64 releases.

I think this statement is wrong. The Dockerfile where you updated the base image doesn't build anything of FDB and actually requires that pre-compiled binaries exist, either locally or as a release. You probably want to create a new build support image: https://github.com/FoundationDB/fdb-build-support, thought I don't think we have plans to support RockyLinux 10 and risc64, so all of this would probably a community effort so far.

RHEL moves slowly. Debian / Ubuntu / Alpine derivative distros have included riscv64 cross-compile support since many years ago, before any official releases for that architecture.

EPEL toolchain extras support requires an RHEL 10 derivative (RockyLinux 10 i.e.) and work is scheduled "sometime in the future" when there are going to be pre-compiled EPEL releases for riscv64. This is expected in 2026 and does depend on RHEL 10 derivative, so the first step is getting the target build environment going where FDB is built.

In addition I'm a bit sceptical to use a x.0 version/release as the default version for any production setup.

It may be better to modify the script to accept an environment variable to choose the rocky version, that would be defaulted to 9.6.

I think, given that we have no rsic64 binaries, the benefit of doing that would be quite limited and I would also assume that quite a few things will break either with RockyLinux 10 an/or risc64. This also makes it hard to validate things work since we cannot build those images without the fdb binaries.

RockyLinux 10 is what you're already targeting with Python 3.12 over Python 3.9 although I don't have any comment for the real engineering concerns of a more recent GCC compiler and security hardening over RockyLinux 9.

My ambition is to get a mail server with FDB by default tooled up for riscv64 releases to compile from nuts-to-bolts on riscv64; if I can't compile it on riscv64 then it's a non-starter and I'll re-invest that time into gutting FDB from riscv64 releases. Either way is fine with me. The non-RHEL world is already there with riscv64 support, PyPI has riscv64 wheels officially, hardware improvements are fully exponential and things are moving forward quickly now for this architecture. If you like the idea of community support just meet it halfway w/ a RHEL10 derivative for all the build environment and the rest should happen this coming year. None of that to the exclusion of proper testing and engineering, of course.