Please branch and build pcs in epel9. If you do not wish to maintain pcs in epel9, or do not think you will be able to do this in a timely manner, the EPEL Packagers SIG would be happy to be a co-maintainer of the package; please add the epel-packagers-sig group through https://src.fedoraproject.org/rpms/pcs/addgroup and grant it commit access, or collaborator access on epel* branches.
*** Bug 2251819 has been marked as a duplicate of this bug. ***
Note: this is part of the High Availability add-on in RHEL, so it's eligible for EPEL per the policy.
Davide, we build pcs for Fedora https://packages.fedoraproject.org/pkgs/pcs/pcs/ , RHEL and CentOS stream https://gitlab.com/redhat/centos-stream/rpms/pcs . I don't see why we would build it for EPEL on top of that. Could you explain what would be a point in doing so? Thanks.
pcs isn't actually shipped in RHEL and CentOS Stream proper -- it's only shipped as part of the HA channel. Branching and building it for EPEL would make it available to systems that don't use the HA channel, and it would also make it available to EPEL in general (note that EPEL and HA can and do conflict). This is akin to what we did in https://bugzilla.redhat.com/show_bug.cgi?id=2121777 for corosync, except in this case we can just branch the package directly (instead of having to make a -epel package) because all the subpackages for pcs are currently shipped in HA.
I don't see any issues with including pcs in EPEL. However, to minimize potential conflicts for RHEL HA users who might also enable EPEL, I would prefer using the pcs-epel package name. Additionally, for pcs to function effectively, it requires the knet and pacemaker packages.
We use the *-epel scheme for packages that have a SRPM in RHEL, but have subpackages that are not shipped in RHEL. This set up is needed to avoid SRPM conflicts that tools like fedpkg check for. The suffix is only used on the SRPM, not the RPMs. Adding the suffix to RPMs would cause problems with other RPMs that may depend on it, and would also confuse users who are trying to install it by name. https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/ For example, the corosync SRPM creates corosync, corosync-vqsim, corosynclib, and corosynclib-devel, but only corosync-vqsim and corosynclib are shipped in BaseOS/AppStream/CRB. EPEL's corosync-epel SRPM provides the missing corosync and corosynclib-devel RPMs. EPEL policy allows these RPMs to overlap with RPMs from HA, because HA is not part of the "target base" in EL9. https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy As Davide pointed out, all of the pcs RPMs are in HA, so there is no SRPM conflict to work around. Creating a pcs-epel distgit repo would result in more work to keep the separate spec files in sync across the two distgit repos. The correct solution is to add an epel9 branch to the pcs distgit repo. If you do not want to maintain such a branch, you can add Davide or the EPEL Packagers SIG with commit or collaborator access. If you want to ensure RHEL HA users get the HA RPMs instead, prefix the EPEL 9 package release with 0 to ensure it sorts lower. This is what corosync-epel does.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.