Of what use a spinner, when it freezes for longer than it runs, but the app eventually returns output after all, so the app itself is still working, which a spinner display is /supposed/ to demonstrate by continuing to spin? This has been annoying me for quite some time, I'd guess for years by now, but it hasn't been fixed, probably because it's not quite irritating enough for anyone (including me) to have filed a bug... until now. Emerge's dep-calculation spinner runs for awhile, then quits, often apparently (I've not measured the actual time, but it seems that way) for longer than it spun, before either spitting out the results (I use --ask by default) or going back to spinning, only to freeze again. This is particularly obvious when using FEATURES=candy, but still occurs without it. Presumably the problem is because emerge goes into some CPU-intensive routine that doesn't update the spinner until it is done. Can some "spin the spinner" breaks be added so it's obvious it's still working? FWIW, currently portage-2.3.24-r1, but as I said it has been that way for a long time now, I'd suppose since 2.2 timeframe if not earlier. (And FWIW, bugzie's portage version selector needs upgraded or perhaps removed if it's no longer useful. 2.2 is the last it shows. No 2.3 to select.)
The depgraph _solve_non_slot_operator_slot_conflicts and _slot_operator_trigger_reinstalls methods both have loops where the spinner is not currently called.
