Już to znalazłem czytając źródła “emerge”.
“emerge” ma ‘scheduler’ w “/usr/lib/python3.11/site-packages/_emerge/Scheduler.py”, który zawiera od linii 1524:
# By default, merge-wait only allows merge when no builds are executing.
# As a special exception, dependencies on system packages are frequently
# unspecified and will therefore force merge-wait.
is_system_pkg = build.pkg in self._deep_system_deps
if not build.build_opts.buildpkgonly and (
"merge-wait" in build.settings.features or is_system_pkg
):
self._merge_wait_queue.append(merge)
if is_system_pkg:
merge.addStartListener(self._system_merge_started)
else:
self._task_queues.merge.add(merge)
merge.addExitListener(self._merge_exit)
self._status_display.merges = len(self._task_queues.merge)
Za wyłączenie tego mechanizmu odpowiada “-merge-wait” w zmiennej FEATURES.
⁂
Jednak według mnie powinno być to trochę inaczej rozwiązane.
Jeśli ‘scheduler’ gwarantowałby zatrzymywanie kompilacji przebiegającej w osobnych wątkach i wtedy wykonywał “merge”, to wtedy ten mechanizm mógłby pozostać włączony. Ale do tego najlepiej potrzebna by była wiedza o zależnościach kompilacji pakietów od tych, które są właśnie skompilowane.