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. -- _______________________________________________ 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
