Description of problem: A library name conflict exists between grpc and libgpr-devel (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. ---- I filed an identical bug against grpc. Given the age of the conflict, I think neither package is “at fault” today, but I unfortunately can’t file a single issue affecting two components at once. Let’s arbitrarily choose to conduct discussion in the grpc bug rather than in this one. I’ll set this bug to depend on the other.
Correction to title and original text: the conflict is with libgpr, not libgpr-devel.
Thank you for the report. I'll see what can be done from gprbuild side. I don't think we have usage for libgpr except gnatcoll as for today
(In reply to Pavel Zhukov from comment #2) > Thank you for the report. I'll see what can be done from gprbuild side. I > don't think we have usage for libgpr except gnatcoll as for today Thanks for looking into it, and for considering doing something on the gprbuild side. (It’s probably a lot harder to change anything on the grpc side, but I’m always willing to consider and try things.)
(In reply to Ben Beasley from comment #0) > Let’s arbitrarily choose to conduct discussion in the grpc bug rather than > in this one. Well, discussion seems to have begun here instead, so I'm continuing that, and copying Dan from the other CC list to this one. Let's have everyone in the same CC list. The conflict doesn't affect end users. It affects only developers who need to link something to GRPC and also use some Ada program linked to GPRbuild's GPR library. That's probably rather few people, which is probably why the conflict hasn't been discovered before. From a human point of view, it can be confusing if the library called "libgpr" isn't in the package with the same name. From a purely technical point of view, renaming the .so file in GPRbuild should be easy as it's usually not referenced directly. The names that matter are the subpackage name "libgpr-devel" and the filename "gpr.gpr". Other GPR files reference gpr.gpr, where the library name is specified. Gnatcoll and any users' own projects should just need rebuilding. I'd like to know how much trouble a name change in GRPC would cause. If all usage goes through the PKGconfig file, then renaming the .so file might be equally easy there. There is some value in consistency in filenames between Debian and Fedora. I agree that Google is probably indifferent. Still, I suppose it wouldn't hurt to let them know that such short names cause trouble. In the Debian bug report, Nicolas Boulenguez mentioned that he hadn't received an answer from Adacore for months, so they don't seem too willing to change the name. If it is decided to change the name in GPRbuild, then I suggest to do it in January when I expect that a new GCC will necessitate a rebuild of all Ada code as usual. As a tangent, shouldn't GPRbuild's libgpr have a versioned soname, and an unversioned symlink in libgpr-devel?
> The conflict doesn't affect end users. It affects only developers who need to link something to GRPC and also use some Ada program linked to GPRbuild's GPR library. That's probably rather few people, which is probably why the conflict hasn't been discovered before. Agreed, only end-users who are developers using the grpc C or C++ APIs will have grpc-devel installed, and the overlap of these developers with those working in the Ada ecosystem is presumably small if not nonexistent. Fedora policy forces us to resolve the conflict, but the impact is low enough that we can afford to take our time and move carefully and correctly. ----- > I'd like to know how much trouble a name change in GRPC would cause. If all usage goes through the PKGconfig file, then renaming the .so file might be equally easy there. There are currently only three packages in Fedora (bear, frr, perl-grpc-xs) that link against the C core API directly. Most dependencies on grpc are via the various Python packages. So even if there is a hard-coded “-lgpr” floating around somewhere, it can probably be handled easily. That said, I have *no idea* how much end-user-who-is-a-developer code might be out there that uses the Fedora grpc package, and whether a renaming would be significantly disruptive to these users or not. Technically, a downstream renaming of libgpr in grpc might be a little tedious but is probably feasible. Upstream supports several build systems: primarily Bazel and CMake, but there is also deprecated support for plain Makefiles. All of these build configurations are generated from a couple of YAML files using ad-hoc code that is also in the source tree: https://github.com/grpc/grpc/tree/v1.41.1/tools/buildgen. Historically, this code required Python 2, so it wasn’t possible to run it downstream. Now it uses Python 3, so it might be possible to patch the YAML and regenerate the CMakeLists.txt. Otherwise, renaming would mean patching the seventeen-thousand-line generated CMakeLists.txt, which isn’t as hard as it sounds. It would be a little tedious, since it would probably have to be manually rebased every release (i.e. every couple of months), but this would be a straightforward process. The Python extension build within grpc actually recompiles all of the C core code and links it statically into the Python extension rather than depending on the system-wide C library. This is allowable because it’s all part of the same package, created from the same source RPM and source tree in the same build. I would still change it if I could easily do so (if nothing else, to reduce package sizes) but in this case it’s one fewer thing to worry about patching. If I have some time, I’ll try to create a proof of concept COPR to see what it would look like to rename the grpc libgpr.so downstream. ----- > I agree that Google is probably indifferent. Still, I suppose it wouldn't hurt to let them know that such short names cause trouble. You’re right. I just filed an issue there describing the situation and asking if renaming is a possibility. https://github.com/grpc/grpc/issues/27850
> Technically, a downstream renaming of libgpr in grpc might be a little tedious but is probably feasible. Upstream supports several build systems: primarily Bazel and CMake, but there is also deprecated support for plain Makefiles. All of these build configurations are generated from a couple of YAML files using ad-hoc code that is also in the source tree: https://github.com/grpc/grpc/tree/v1.41.1/tools/buildgen. Historically, this code required Python 2, so it wasn’t possible to run it downstream. Now it uses Python 3, so it might be possible to patch the YAML and regenerate the CMakeLists.txt. Otherwise, renaming would mean patching the seventeen-thousand-line generated CMakeLists.txt, which isn’t as hard as it sounds. It would be a little tedious, since it would probably have to be manually rebased every release (i.e. every couple of months), but this would be a straightforward process. It’s not possible to regenerate everything from its ultimate sources using tools/buildgen/generate_projects.sh, since that starts with the Bazel BUILD file, and Bazel will probably never be packaged in Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=2015277, https://bugzilla.redhat.com/show_bug.cgi?id=1470842). Starting with the resulting build_autogenerated.yaml (along with build_handwritten.yaml), and patching those along with several of the template files in templates/ and a couple of files in tools/buildgen/plugins/, should be a workable approach in theory. I’m having a bit of trouble getting it to work in practice, since it also requires either having bundled boringssl sources present (which they aren’t in the GitHub archive) or carefully patching out boringssl support in quite a few places. Patching the generated build system files may yet be a more practical way forward if renaming grpc’s libgpr.so proves the better choice.
Patching CMakeLists.txt to rename libgpr in grpc (downstream) is feasible. Proof of concept PR: https://src.fedoraproject.org/rpms/grpc/pull-request/8 This would be a breaking change comparable to a .so version bump, which happens regularly in grpc. I think it would therefore make sense *not* to try to backport it to stable releases. I don’t think anything has an explicit build dependency on grpc’s gpr—only via 'pkgconfig(grpc)`, `pkgconfig(grpc++)`, `cmake(grpc)`, or similar—so nothing else in the distribution should need to be patched. I’d have to try it out in a COPR to be sure, though. The patch would have to be rebased relatively frequently, but I could probably automate it by distilling it into a sufficiently reliable sed invocation. ---- The upstream bug in grpc asking about this received two assignees on 2021-11-02, but there hasn’t been any feedback so far.
Here's how GPRbuild can be patched to resolve the conflict: https://src.fedoraproject.org/rpms/gprbuild/pull-request/1#request_diff That shouldn't be much of a maintenance burden. It does appear that a downstream renaming is less trouble in GPRbuild than in GRPC, although it feels a bit like rewarding Google for using a bloated and unpackageable build system. Pavel, what do you think?
Pavel accepted my pull request, so the conflict will be resolved in Fedora 36, unless something breaks unexpectedly.
> …although it feels a bit like rewarding Google for using a bloated and unpackageable build system. Yes, I sympathize with this feeling. The organization of grpc is a sprawling mess, and it’s barely possible to keep it adequately packaged. > Pavel accepted my pull request, so the conflict will be resolved in Fedora 36, unless something breaks unexpectedly. Thanks! Once there is a new build of gprbuild, I’ll remove the Conflicts in grpc, and close the relevant Bugzilla issues (if Pavel hasn’t already done so).
The switch to GCC 12 was rough, with an API change and a very inconvenient compiler bug delaying the rebuild, but now there is finally a new libgpr package where the file is named libgnatprj.so.
Thanks! I’ve just removed the Conflicts in grpc. When that build finishes, it will close the corresponding grpc bug (https://bugzilla.redhat.com/show_bug.cgi?id=2017576).