Revisting conflicts policy for EPEL compat packages

I originally filed this as an issue for the EPEL Steering Committee. We discussed it at the last meeting, and the general consensus was to open a wider discussion about the topic.

In Fedora, it is allowed for compat packages to conflict with their non-compat equivalents. This is often necessary for compat -devel packages for things like unversioned soname symlinks, pkgconfig files, etc. It’s fairly rare that relocated development files are supported by packages that need to build against those development files. Relevant section from the guidelines:

It is acceptable to use Conflicts: in some cases involving compat packages. These are the cases where it is not feasible to patch applications to look in alternate locations for the -compat files, so the foo-devel and foo-compat-devel packages need to Conflict:. Whenever possible, this should be avoided.

In EPEL, we allow the same behavior between EPEL packages, but not between EPEL packages and RHEL packages. Relevant section from the guidelines:

Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat packages than Fedora. When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the Conflicts Guidelines. At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.

This policy includes the phrase “at this time”, which has stuck out to me for a while. I didn’t write it in the original policy, but I do agree with the sentiment that it is worth revisiting. I think it would be appropriate to allow EPEL compat -devel packages to conflict with RHEL -devel packages. As mentioned in the policy, EPEL has a greater need for this than Fedora does, yet we are severely limited by not being able to ship correct compat -devel packages when the corresponding non-compat package is in RHEL. EPEL’s policy is that EPEL packages “enhance” the base distribution without “disturbing” or “replacing” packages from the base distribution. Most users do not install -devel packages, so they would not be disturbed by some -devel packages not being able to be installed at the same time. These compat package also have names that would be hard to mistake for the non-compat package. I’ve never heard of an instance of multiple conflicting -devel packages causing an issue in Fedora, or in EPEL (between EPEL packages). Most commonly these packages are installed during package builds of other software, which regular users can later consume without ever seeing the conflicts, because the corresponding compat library packages tend to be parallel installable and cause no disruption at all.

What are your thoughts about this potential adjustment of EPEL policy?

Here are some examples of this type of conflict within Fedora:

  • catch2-devel / catch-devel
  • drumstick0-devel / drumstick-devel
  • tbb2020.3-devel / tbb-devel
  • libgit2_1.6-devel / libgit2-devel
  • wlroots0.15-devel / wlroots-devel

Here are some examples of this type of conflict within EPEL:

  • minizip1.2-devel / minizip-devel
  • libsodium13-devel / libsodium-devel
  • compat-libtidy-devel / libtidy-devel
  • libmodulemd2-devel / libmodulemd-devel
  • libgit2_1.3-devel / libgit2-devel

Here are some examples of this type of conflict within RHEL:

  • libev-libevent-devel / libevent-devel
  • ORBit2-devel / ORBit-devel
  • bind9.16-devel / bind-devel
  • mariadb-devel / mysql-devel
  • python3.11-pybind11-devel / pybind11-devel

I even found one example of RHEL devel package (pipewire-jack-audio-connection-kit-devel) conflicting with an EPEL devel package (jack-audio-connection-kit-devel). Technically this EPEL package should be retired under the current rules, but if we make this adjustment to the policy it would be allowed.

I think it’s completely reasonable to relax this policy for any package that is not used at runtime (e.g. -devel packages).

I do, however, think that the runtime packages should not conflict with RHEL content, as that would cause significant supportability headaches.

I think it’s probibly ok to relax this. We will need to be very clear in
docs whats allowed and not.

The only downside I think is that it’s less true to say “EPEL never
conflicts with any RHEL package”. It adds some nuance. However, I think
it makes sense here, so I am in favor.

I’ve posted my initial draft of the policy change wording. Please take a look.

https://pagure.io/epel/pull-request/257

After review and acceptance by the EPEL Steering Committee, this has been merged and is now policy.

https://pagure.io/epel/issue/247#comment-883241