Performing emerge -uDN --with-bdeps=y @world and a new version dev-lang/go is available, but app-adming/mongo-tools is blocking it.
Steps to Reproduce:
1. emerge -uDN --with-bdeps=y @world
(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"
dev-lang/go-1.13.6 to be compiled and installed.
Created attachment 603338 [details]
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?
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.