I'm not sure how to handle this (can google-cloud-cpp use a newer version of protobuf?), but the version of protobuf needed by the latest google-cloud-cpp-0.10.0-r1 now conflicts with the stable version that other packages are trying to pull in. For example, !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/protobuf:0 ... dev-libs/protobuf:0/21= required by (net-libs/google-cloud-cpp-0.10.0- r1:0/0::gentoo, installed) USE="" ~dev-libs/protobuf-3.11.4 required by (dev-python/protobuf-python-3.11.4:0 /22::gentoo, ebuild scheduled for merge) USE="" PYTHON_TARGETS="python3_6 -python2_7 -python3_7 (-python3_8)"
(that's the only version of protobuf-python in the tree)
o.O net-libs/google-cloud-cpp depends on dev-libs/protobuf:= ? do you need to emerge -Du @world maybe?
I'm not crazy, you're crazy =) $ grep protobuf google-cloud-cpp-0.10.0.ebuild RDEPEND="dev-libs/protobuf:=
oh, no i meant like it just has :=, it doesn't have any version dependency on protobuf just the normal subslot rebuild. It should just work with any version, it just needs to be rebuilt after protobuf is upgraded. I dont know why portage doesn't just rebuild it tho? Maybe there's some other dep that is holding protobuf back? cuz google-cloud-cpp doesnt care.
Oh, portage is just lying to me. Why didn't I think of that? Ultimately this was user error: I originally installed google-cloud-cpp with ACCEPT_KEYWORDS="~amd64", but didn't add it to my package.accept_keywords. Now portage needs to rebuild it, but it won't because it's not keyworded. And instead of saying that, it's making up some nonsense about the version of protobuf (dev-libs/protobuf:0/21= is what's cached in the VDB). After keywording it, emerge -puDN @world looks like it might do the right thing. Sorry for the noise.
The rebuild failed, reminding me of why I used a --oneshot emerge in the first place: https://bugs.gentoo.org/691352 Please take a look at that if you get some time =)
