Summary: | app-admin/mongo-tools-4.2.2 blocks dev-lang/go-1.13.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Neil <nshephard> |
Component: | Current packages | Assignee: | Ultrabug <ultrabug> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | hydrapolic |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Description
Neil
2020-01-15 10:42:07 UTC
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. |