Please file new bugs and have them block this one, thanks.
It seems that #913923 is not related anymore with this bug.
My apologizes if I should have put this elsewhere, but the newer protobuf adds pkg-config flags to link libraries from abseil-cpp, so arguablly anything that DEPEND/RDEPEND on dev-libs/protobuf also needs to do the same for dev-cpp/abseil-cpp. I was thinking about how to handle this on ChromeOS and I am thinking it might make sense to create a virtual/protobuf that depends on both dev-libs/protobuf and dev-cpp/abseil-cpp and refactor everything else that depends on dev-libs/protobuf to depend on virtual/protobuf instead. What do you all think?
(In reply to Allen Webb from comment #2) > My apologizes if I should have put this elsewhere, but the newer protobuf > adds pkg-config flags to link libraries from abseil-cpp, so arguablly > anything that DEPEND/RDEPEND on dev-libs/protobuf also needs to do the same > for dev-cpp/abseil-cpp. I was thinking about how to handle this on ChromeOS > and I am thinking it might make sense to create a virtual/protobuf that > depends on both dev-libs/protobuf and dev-cpp/abseil-cpp and refactor > everything else that depends on dev-libs/protobuf to depend on > virtual/protobuf instead. > > What do you all think? Actually from talking to vapier, that doesn't work because we want the slot operator. I might go with an eclass to manage the deps, but that seems a bit heavyweight.
(In reply to Allen Webb from comment #2) > My apologizes if I should have put this elsewhere, but the newer protobuf > adds pkg-config flags to link libraries from abseil-cpp, so arguablly > anything that DEPEND/RDEPEND on dev-libs/protobuf also needs to do the same > for dev-cpp/abseil-cpp. I was thinking about how to handle this on ChromeOS > and I am thinking it might make sense to create a virtual/protobuf that > depends on both dev-libs/protobuf and dev-cpp/abseil-cpp and refactor > everything else that depends on dev-libs/protobuf to depend on > virtual/protobuf instead. > > What do you all think? This is one of those pesky situations which comes up every so often (e.g. gtk with adding glib and other stuff depending on USE, or cairo, pango, ...). We normally don't worry too much (because the package using protobuf itself doesn't care about it, it only cares about a working protobuf, and its dependencies will include abseil-cpp) but the libraries in this kind of situation usually are ABI stable and that's not the case here. But it's tricky here, because if you say, downgrade abseil-cpp, right now, protobuf will get rebuilt, but none of the things built against protobuf+abseil-cpp will be. I'm not sure what the best solution is yet, but one option would be to pursue the virtual way but with each version of the virtual pinning a tuple of protobuf+abseil-cpp versions. I don't really like that though..
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cb77397509a76c1eeeb919dedb2b52f744227be commit 8cb77397509a76c1eeeb919dedb2b52f744227be Author: Sam James <sam@gentoo.org> AuthorDate: 2024-05-28 00:12:55 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-05-28 00:13:49 +0000 profiles: mask new protobuf & abseil-cpp Breaks reverse dependencies like protobuf-c (bug #932857) and protobuf-26.1 itself isn't compatible with this abseil-cpp version (bug #932848). In addition, we still need to establish a new approach like a virtual for protobuf because of its abseil dependency - see the discussion in bug #912819. I'm not aware of a real hurry for new abseil/protobuf other than the existing need for us to sort out the aforementioned virtual/ABI mess, so masking is better than the status quo. Closes: https://bugs.gentoo.org/932857 Bug: https://bugs.gentoo.org/932848 Bug: https://bugs.gentoo.org/912819 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 8 ++++++++ 1 file changed, 8 insertions(+)
