Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 705480 - app-admin/mongo-tools-4.2.2 blocks dev-lang/go-1.13.6
Summary: app-admin/mongo-tools-4.2.2 blocks dev-lang/go-1.13.6
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Ultrabug
Depends on:
Reported: 2020-01-15 10:42 UTC by Neil
Modified: 2020-01-20 11:16 UTC (History)
1 user (show)

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

emerge --info (,18.46 KB, text/plain)
2020-01-15 10:43 UTC, Neil

Note You need to log in before you can comment on or make changes to this bug.
Description Neil 2020-01-15 10:42:07 UTC
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-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.
Comment 1 Neil 2020-01-15 10:43:07 UTC
Created attachment 603338 [details]
emerge --info
Comment 2 Tomáš Mózes 2020-01-15 17:07:03 UTC

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
Comment 3 Neil 2020-01-17 15:24:49 UTC
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?
Comment 4 Tomáš Mózes 2020-01-17 17:37:45 UTC
Comment 5 Neil 2020-01-18 20:34:22 UTC
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?
Comment 6 Tomáš Mózes 2020-01-20 06:00:48 UTC
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
Comment 7 Neil 2020-01-20 07:47:48 UTC
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?
Comment 8 Tomáš Mózes 2020-01-20 10:01:21 UTC
Maybe, I don't know :(

Next time you could attach the full emerge output (maybe calling emerge with --debug).
Comment 9 Neil 2020-01-20 11:16:29 UTC
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.