We discussed this at today's EPEL Steering Committee meeting.

https://meetbot.fedoraproject.org/fedora-meeting/2023-06-07/epel.2023-06-07-19.59.html

The general consensus was that if it is desired to regularly update a package in an incompatible manner, that package would be a better fit in a copr repo instead of EPEL.

Excluding development files in order to regularly update a package in an incompatible manner is not explicitly allowed in the Fedora packaging guidelines (which EPEL also follows whenever possible), so we agreed to defer that question to the Fedora Packaging Committee. Please file a ticket on their tracker.

https://pagure.io/packaging-committee/issues

Ok, thanks. Here is the new ticket:
https://pagure.io/packaging-committee/issue/1283

Ultimately the gpsd-minimal package was added to RHEL 9.

https://access.redhat.com/errata/RHEA-2023:4865

And a gpsd-epel package was added to epel9
https://koji.fedoraproject.org/koji/buildinfo?buildID=2285815

And the regular gpsd package was retired from epel9.

Did you test it? I'm not sure if newer gpsd is supposed to work with older libgps. IIRC the current version doesn't work with the EPEL8 libs. If it works now, it could break in future.

It would be best to keep the EPEL9 gpsd.

The gpsd in RHEL (gpsd-minimal) is built with everything self-contained. It doesn't look at the libraries in EPEL. I believe part of this is not just because of EPEL, but incase any end users have other versions of gpsd installed.

But, gpsd-minimal binaries (in RHEL9), have the same names as the epel gpsd and gpsd-clients (in EPEL9), which is why we had to remove the epel packages that provide those binaries.

Although I know it has been tested, if you find that gpsd-minimal doesn't work with the EPEL libraries installed, you should open a RHEL ticket. Because they wanted it to work that way.

I'm not sure who is they, but I don't remember seeing any requirements for the RHEL9 gpsd to be compatible with the EPEL9 libs. The main point of not shipping the libs was that nothing would break if it is rebased. Alternative name was used to avoid having two different packages with same name.

gpsd-minimal is marked as conflicting with gpsd. AFAIK there is no technical problem for the two packages to be available at the same time. dnf can handle conflicts. That EPEL rule about not allowing conflicting packages should be revisited. I suspect it's now just cargo culting from the yum era.

Sorry, I didn't notice who had said that.

I'm reading in the EPEL conflicting packages policy
https://docs.fedoraproject.org/en-US/epel/epel-policy/#policy_for_conflicting_packages
I'm noticing a couple of things.
* First it doesn't say what it means by what a conflict is. Is this a package name conflict only, does it also extend to the Conflict statement, does it also involve conflicting files (which would require a Conflict statement).
* Second, although the first bullet point says there should be no conflicts, the third bullet point talks about working together with the RHEL package maintainer if there are conflicts "on a case by case basis"

So, I agree with you. The policy needs to be looked at.

The policy needs to be looked at and worded better, but it is not cargo culting from yum.

The conflict which generally causes problems is a binary or library file name conflict. Many scripts and tools are written for large enterprises using things like 'dnf install //<binary' aka dnf install /usr/sbin/gpsd and many of them rely on the fact that dnf/yum//etc does not error out to say 'conflict' etc.

The case by case basis has been mainly for things in 'layered' products or where the RHEL package has gained a 'conflict' usually due to bad packaging. (aka they weren't going to ship /usr/bin/costs-too-much-too-support but EPEL did package it as something. Then someone who didn't know about that changes a file section and /usr/bin/costs-too-much-too-support got into a RHEL release. [This is not much of a problem as RHEL tooling learned not to allow that.]

The above doesn't mean we should keep that section as is, but I hope it better illustrates why it existed.

Another reason why conflicts are generally disallowed for EPEL packages is because a conflict (explicit or implicit) can halt an upgrade, which is clearly against the "only enhance and never disturb" policy.

If the original reason for that rule was to prevent broken upgrades or unexpected new dependencies, then it should say that and not ban all conflicts.

Implicit conflicts cause rpm transactions to fail. That's bad and needs to be avoided.

Explicit conflicts are handled by dnf. If the solution requires a package to be removed, dnf makes that clear and suggests the --allowerasing option. A policy requiring packages to not add or change dependencies in one release in such a way that could require erasing packages would make sense to me, even in Fedora. Not allowing any conflicts between RHEL and EPEL packages, when both RHEL and EPEL are allowed to have conflicts within their repositories, does not make sense to me.

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

Please continue any further discussion there.