Bug 912819 – [Tracker] Breakage with dev-libs/protobuf-23.3, dev-cpp/abseil-cpp-20230802

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Sam James 2023-08-22 10:26:43 UTC]

Please file new bugs and have them block this one, thanks.

[Comment 1 Zentoo 2023-10-28 07:19:33 UTC]

It seems that #913923 is not related anymore with this bug.

[Comment 2 Allen Webb 2023-11-08 20:34:18 UTC]

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?

[Comment 3 Allen Webb 2023-11-08 21:38:56 UTC]

(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.

[Comment 4 Sam James 2023-12-03 06:42:05 UTC]

(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..

[Comment 5 Larry the Git Cow 2024-05-28 00:14:55 UTC]

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 <[e-mail]>
AuthorDate: 2024-05-28 00:12:55 +0000
Commit:     Sam James <[e-mail]>
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 <[e-mail]>

 profiles/package.mask | 8 ++++++++
 1 file changed, 8 insertions(+)