epel

#185 Request for advice: thirdparty EL repo conflicting with EPEL
Closed: Fixed by mystro256. Opened by mystro256.

Closed: Fixed
Reopen Issue

Hi, I was just looking for advise, as I didn't see anything explicitly documented.

Two packages have been introduced into EPEL 8 and 9 (ported from Fedora):
- rocminfo
- rocm-device-libs

and I have another package "rocm-opencl" under package review that I intend on pushing to EPEL after Fedora.

These packages conflict the RHEL/CentOS ROCm repositories provided by AMD [1]. For now I suggested to them to set their repo priority to 50 (default is 99), but I would like to foster a good symbiotic relationship, as they rely on packages from EPEL.

So my questions are: is there any specific advise I can give other than "just don't conflict with EPEL package names"? Is there any documentation targeted towards 3rd party repositories with in regards to EPEL? Are there some good conventions I can suggest to avoid conflicts in the future?

I noticed some documentation, but it appears targeted to Fedora, not EPEL [2].

Thanks!

[1] e.g. http://repo.radeon.com/rocm/centos8/latest/main/
[2] https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/

Sticky vendors could help here, maybe, but afair it's not turned on by default. We do that for Hyperscale, see the "sticky vendor" section in https://blog.centos.org/2022/04/centos-hyperscale-sig-quarterly-report-for-2022q1/ and issue it links to (I'll get this documented properly on our end too).

My advice is two fold. The first is as you said "don't conflict with EPEL package names"

The second is get their packages in EPEL.

If the licenses allow it, there is no reason AMD / Intel / Samsung / cannot put their package in EPEL itself.

@dcavalca I'm not sure I understand the value of this over setting the priority in the repo file.
Perhaps I misinterpret the purpose of this.

@tdawson An interesting idea, but I think there's a few challenges to this.

I think the main issue with AMD packaging ROCm in EPEL is that LLVM is too old for the latest ROCm. EL tends to be a release behind due to timing. The version of these two EPEL packages is currently a minor release behind Fedora, and will likely continue being there until EL 8.7/9.1 is released with a bumped LLVM.

If you look into the ROCm repository, they have their own fork of LLVM, which is a slimmed down bleeding edge fork. Is this kosher to do in EPEL? I know with Fedora, it's strongly preferred to only have one LLVM.

Ah, that's right. Licenses AND dependencies prevent things from going into EPEL.

Has this been answered good enough?
Can we close this ticket?

Yes, thank you

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

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

Please continue any further discussion there.
Metadata
None
None
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.