On Fri, Oct 24, 2025 at 9:23 AM Tim Flink <[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/ > > 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 > > > --------------- > 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.
-- _______________________________________________ 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
