Bug 2017576
| Summary: | Library name conflict between grpc-devel and libgpr (from gprbuild): %{_libdir}/libgpr.so | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ben Beasley <code> |
| Component: | grpc | Assignee: | Ben Beasley <code> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | code, dan.cermak |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | grpc-1.41.1-12.fc36 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-02-06 02:05:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2017582 | ||
Until a solution can be found, I am adding an explicit “Conflicts: libgpr” to the “grpc-devel” package (https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_implicit_conflicts). Correction to title and original text: the conflict is with libgpr, not libgpr-devel. Discussion is in progress on the corresponding gprbuild bug: https://bugzilla.redhat.com/show_bug.cgi?id=2017582 FEDORA-2022-27afa9089f has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-27afa9089f FEDORA-2022-27afa9089f has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |
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.