Performing emerge -uDN --with-bdeps=y @world and a new version dev-lang/go is available, but app-adming/mongo-tools is blocking it. Reproducible: Always Steps to Reproduce: 1. emerge -uDN --with-bdeps=y @world Actual Results: dev-lang/go:0 (dev-lang/go-1.13.6:0/1.13.6::gentoo, ebuild scheduled for merge) USE="-gccgo -system-bootstrap" pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-lang/go-1.13.5:0/1.13.5::gentoo, installed) USE="-gccgo -system-bootstrap" pulled in by dev-lang/go:0/1.13.5= required by (app-admin/mongo-tools-4.2.2:0/0::gentoo, installed) USE="-sasl ssl" ^^^^^^^^^^ Expected Results: dev-lang/go-1.13.6 to be compiled and installed.
Created attachment 603338 [details] emerge --info
https://github.com/gentoo/gentoo/blob/master/app-admin/mongo-tools/mongo-tools-4.2.2.ebuild#L18 Mongo-tools just depends on go and mongo-tools should be rebuilt when the go slot is changed. Try emerge -av1 dev-lang/go app-admin/mongo-tools
Thanks, that appears to have worked. I don't normally need to do this sort of thing though. Should updating dev-lang/go not have triggered app-admin/mongo-tools to have been re-emerged?
Yes
If that is the case why has this report been marked as RESOLVED INVALID? I've had similar with =x11-base/xorg-server-1.20.7 not being upgraded because of conflicts with already emerged packages that were installed and compiled with earlier versions. I have --with-bdeps=y set as an EMERGE_DEFAULT_OPTS, so I'm wondering if there is something awry in Portage (=sys-apps/portage-2.3.84-r1) causing this?
With mongo-tools-4.2.2 having installed, this is the output from my ~amd64 desktop: # emerge -uDNva1 --with-bdeps=y @world ... [ebuild r U ] dev-lang/go-1.13.6:0/1.13.6::gentoo [1.13.4:0/1.13.4::gentoo] USE="-gccgo -system-bootstrap" 21,125 KiB ... [ebuild rR ] app-admin/mongo-tools-4.2.2::gentoo USE="ssl -sasl" 0 KiB
I have --with-bdeps=y set as part of my EMERGE_DEFAULT_OPS (as shown in the emerge --info I attached) and this didn't happen when I was upgrading @world (as I do daily) with emerge -uDN @world as I reported originally. Could it be something to do with the dependency graph not being correctly calculated/deep enough?
Maybe, I don't know :( Next time you could attach the full emerge output (maybe calling emerge with --debug).
I will in the future, as I mentioned above there were similar issues with xorg-server and I didn't want to cause confusion by conflating the two.