On 10/24/25 11:02 AM, Troy Dawson wrote:
On Fri, Oct 24, 2025 at 9:23 AM Tim Flink <[email protected]
<mailto:[email protected]>> wrote:
Hi, I'm one of the folks working on ROCm packaging in Fedora and
EPEL. We're looking to continue updating the ROCm stack in EPEL10
but recognize that this will involve some backwards-incompatible
changes. We realize that this is a little outside what has
historically been done in EPEL and as such, are starting with a
discussion on epel-devel and will follow up with a ticket for the
EPEL steering committee similar to what is outlined in the
incompatible upgrades policy [1].
[1] https://docs.fedoraproject.org/en-US/epel/epel-policy-
incompatible-upgrades/ <https://docs.fedoraproject.org/en-US/epel/
epel-policy-incompatible-upgrades/>
I have included our proposal at the end of this email and welcome
discussion around how we can minimize the pain to others while
keeping ROCm up to date in EPEL10.
Thanks,
Tim
----------
tl;dr
The ROCm packagers are proposing to make backwards incompatible
changes in a controlled way so that we can make sure that the latest
ROCm features are available to EPEL10 users.
------------
Background
------------
ROCm is an open-source software platform that provides the tools for
programming AMD Graphics Processing Units (GPUs), from low-level
kernels to high-level end-user applications including AI and HPC.
There seems to have been a decent amount of interest in having the
ROCm packages available in EPEL and we've been able to get the vast
majority of the packages in Rawhide into EPEL for ROCm 6. ROCm 7 has
recently been released and we would like to import this new version
from Rawhide to EPEL but ROCm 7 is a major release and it will
introduce breaking changes.
This is not going to be the only backwards-incompatible change to
ROCm over the EL10 lifecycle. For example, ROCm 8 is expected to
land sometime next year or there could be changes between minor
releases and we want to make the case that it would be worth
granting an exception to allow us to keep the latest ROCm available
in EPEL instead of sticking to a single version (6.x in our case)
for all of EPEL10. We have not requested any EPEL9 branches and we
currently have no plans to build ROCm packages for anything older
than EPEL 10.1.
----------
Proposal
----------
We'd like to continue updating ROCm in EPEL but don't want to ignore
the existing policies and intents around making changes all the
time. As such, we're requesting and proposing that ROCm package
updates going forward be allowed to break backwards-compatibility so
long follow the following rules:
1. There will only be one minor release of ROCm within a minor
release of EPEL.
This means that the upcoming ROCm 7 will never be part of epel 10.1
because that would be a disruptive, backwards incompatible change.
ROCm 7, if brought into EPEL would be part of 10.2 or later.
2. Backwards incompatible changes could ONLY happen between minor
EPEL releases
Assuming that nothing wholly unexpected happens, this means that
epel 10.2 would get an update to at least ROCm 7.x or maybe even
newer if the release dates work out and stable packages are
available prior to the EPEL 10.2 branching date.
3. The set of ROCm packages consist of all packages co-maintained by
the rocm-packagers-sig that have EPEL branches
This list of packages will likely change over time but can be found
at https://src.fedoraproject.org/group/rocm-packagers-sig <https://
src.fedoraproject.org/group/rocm-packagers-sig>
---------------
Justification
---------------
The justification for our request really comes down to keeping the
latest and greatest features for ROCm available for EPEL10 users.
This includes enabling new hardware as it is released (the upcoming
MI350 accelerators will require ROCm > 7.0 as an example) in
addition to enabling the latest versions of software like pytorch.
In the end, we’re looking to make ROCm as easy to install and use as
possible through better integration with Linux distributions and in
this case, EPEL. This is why we are working to package and update
the ROCm stack in Fedora and EPEL.
Thank you for starting the discussion.
I know you want to talk about EPEL, but I'm curious what the process
is /or will be for Fedora, so I/we can compare.
So far, our process has been similar for Fedora. All of the intentionally
backwards-incompatible changes are made in rawhide and we have kept to one
minor release of ROCm per Fedora release.
The most that we plan on changing within a Fedora release would be something
like the pending update for F43 [1]. ROCm 6.4.3 was current when rawhide
branched but 6.4.4 adds support for some of AMD's newer APUs. That update has
been built and is currently in updates-testing; it will be pushed stable once
F43 releases next week.
Tim
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2025-6ed0814d96
--
_______________________________________________
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
