epel

#354 Proposal: Allow Controlled Backwards-Incompatible Updates for ROCm in EPEL10
Closed: Approved by carlwgeorge. Opened by tflink.

Closed: Approved
Reopen Issue

Introduction

We, the ROCm packagers in Fedora and EPEL are looking to continue updating the ROCm stack in EPEL10 but recognize that this will involve some backwards-incompatible changes. As this is not quite what is traditionally done in EPEL, we are starting with the incompatible upgrade policy since that is close to what we are proposing.

This proposal was sent to epel-devel on 2025-10-24 for discussion, following the incompatible upgrade policy.

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

Metadata Update from @carlwgeorge:
- Issue tagged with: meeting

This seems reasonable to me. +1

This sounds good. +1

We discussed this at today's EPEL Steering Committee meeting. We're generally in favor of this plan, but would like to see how it plays out for ROCm 7 before doing a permanent exception, so for now we just voted on this for the update to version 7.

AGREED: Proposal: Allow Incompatible Updates 7 for ROCm in EPEL10 passed +1(6) -1(0) 0 (1) - 1 person missing

Metadata Update from @carlwgeorge:
- Issue close_status updated to: Approved
- Issue status updated to: Closed (was: Open)

For posterity, here is the update that bumped the ROCm stack from 6 to 7.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-2d35f357ac

This ended up breaking two packages that were not included in the rebuild, but should have been.

I brought this to the maintainers attention today in the AI/ML SIG meeting. @trix noted that python-torch had a build failure, and magma was just forgotten. I've asked that in the future ROCm rebase updates not be pushed to stable unless they're complete and don't break other packages.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/354

Please continue any further discussion there.
Metadata
None

meeting

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.