Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 912819 - [Tracker] Breakage with dev-libs/protobuf-23.3, dev-cpp/abseil-cpp-20230802
Summary: [Tracker] Breakage with dev-libs/protobuf-23.3, dev-cpp/abseil-cpp-20230802
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Arfrever Frehtes Taifersar Arahesis
URL:
Whiteboard:
Keywords: Tracker
Depends on: 909081 912790 912829 912843 913044 913106 913650 913923 915020 915902 917046 923757 909087 912280 912774 912775 912776 912778 912779 912780 912788 912789 912792 912793 912795 912796 912797 912825 912826 912828 912837 912846 912853 912942 912944 913004 913005 913007 913010 913243 913534 913731 913738 913887 914152 914659 914714 919101 919201
Blocks: 915160
  Show dependency tree
 
Reported: 2023-08-22 10:26 UTC by Sam James
Modified: 2024-03-27 21:28 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 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 archtester Gentoo Infrastructure gentoo-dev Security 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..