Description of problem:

A library name conflict exists between grpc and libgpr (a subpackage of gprbuild). Both packages provide %{_libdir}/libgpr.so.

Version-Release number of selected component (if applicable):

All known EVR’s.

How reproducible:


Steps to Reproduce:
1. mock -r fedora-rawhide-x86_64 --dnf-cmd -- repoquery --whatprovides '/usr/lib*/libgpr.so'

Actual results:

grpc-devel-0:1.41.0-2.fc36.i686
grpc-devel-0:1.41.0-2.fc36.x86_64
libgpr-0:2020-7.fc35.i686
libgpr-0:2020-7.fc35.x86_64

Expected results:

EITHER

grpc-devel-0:1.41.0-2.fc36.i686
grpc-devel-0:1.41.0-2.fc36.x86_64

OR

libgpr-0:2020-7.fc35.i686
libgpr-0:2020-7.fc35.x86_64

Additional info:

I am the current maintainer of grpc. I took over the package after it was orphaned. It looks like the conflict was already present when I took over the package. In fact, the conflict has probably existed for many years.

The packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_library_name_conflicts) are very strict: this conflict MUST be resolved somehow.

The advice is to try to convince one upstream to rename the library. That seems unlikely, as the gprbuild project is long-standing and significant within the Ada world, and grpc’s upstream is Google, who are unlikely to see the conflict as a problem. Still, I guess the idea has to be explored.

If neither upstream can be convinced, maintainers are supposed to escalate to FPC and ask for advice on removing the conflict.

----

This has come up in at least a couple of other distributions.

In Arch, gprbuild/libgpr comes from AUR. The conflict was made explicit but not resolved. (https://aur.archlinux.org/packages/libgpr/)

In Debian, the conflict was resolved by renaming libgpr.so in gprbuild to libgnatprj.so. This renaming was done downstream. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945197)

----

Note that both packages have been in the distribution for many years and have a significant number of dependent packages, so simply retiring one is not a feasible solution.

----

This bug exists to track progress on resolving the conflict. The choice to file it against grpc rather than gprbuild is arbitrary; given the age of the conflict, I think neither package is “at fault” today.