Created attachment 915968 [details] emerge --info Currently a user trying to enable ada for gcc leads to portage trying to build every gcc version down the chain. $ USE="ada" emerge -p gcc:14 These are the packages that would be merged, in order: Calculating dependencies ... done! Dependency resolution took 19.78 s (backtrack: 4/20). [ebuild N ] dev-lang/ada-bootstrap-0_p2021-r1 [ebuild NS ] sys-devel/gcc-11.5.0 [14.2.1_p20241221, 15.0.9999] USE="ada* lto* pgo* -objc*" [ebuild NS ] sys-devel/gcc-12.4.1_p20241219 [14.2.1_p20241221, 15.0.9999] USE="ada* lto* pgo* -objc*" [ebuild NS ] sys-devel/gcc-13.3.1_p20241220 [14.2.1_p20241221, 15.0.9999] USE="ada* lto* pgo*" [ebuild R ] sys-devel/gcc-14.2.1_p20241221 USE="ada*" That is unless they tie portages hand and force it to use ada-bootstrap-14. $ USE="ada" emerge -p gcc:14 \=dev-lang/ada-bootstrap-14 These are the packages that would be merged, in order: Calculating dependencies ... done! Dependency resolution took 13.01 s (backtrack: 1/20). [ebuild N ] dev-lang/ada-bootstrap-14 [ebuild R ] sys-devel/gcc-14.2.1_p20241221 USE="ada*" Modifying toolchain.eclass to give higher priority to ada-bootstrap does not help. This appears to be a case where portage naively prefers the already installed package even if the slots differ. I'll be including a portage testcase which makes the issue obvious.
Created attachment 915969 [details, diff] Patch adding testcase Testcase naming is just a literal placeholder as I'm unsure on a concise name. And its xfail.
We're preferring B in || ( A B ) even when B is (much) more expensive because it's another slot of an existing package. I feel like the existing behaviour is mostly okay apart from this case where we're pulling in many old slots. So, a few options: * Evaluate both paths and cost them by # of new packages (we don't do that sort of double-evaluation right now AFAIK just for optimisation, only for discarded candidates?) * Disregard the existing package because it would be an *older* PV, and we could assume that's probably undesirable * Change it so we don't apply this rule (prefer already-installed) if slots are involved * ??? BTW, this same issue came up with dev-lang/rust where it pulled in many old dev-lang/rusts, even though dev-lang/rust-bin was first in the || ( ... ) dep.
Created attachment 915972 [details, diff] Patch adding testcase with dev-libs/B first in the any-of dependency list A more "unreasonable" example as requested by sam. Output without xfail. FAILED lib/portage/tests/resolver/test_placeholder.py::PlaceholdernameTestCase::testplaceholdername - AssertionError: False != True : atoms: (dev-libs/A:4), key: mergelist, expected: ['dev-libs/B-4', 'dev-libs/A-4'], got: ['dev-libs/B-1', 'dev-libs/A-1', 'dev-libs/A-2', 'dev-libs/A-3', 'dev-libs/A-4']
(In reply to Sam James from comment #2) > * Disregard the existing package because it would be an *older* PV, and we > could assume that's probably undesirable It wouldn't be the first time that we specialise "downgrades".
(In reply to Sam James from comment #2) > I feel like the existing behaviour is mostly okay apart from this case where > we're pulling in many old slots. > > So, a few options: > * Evaluate both paths and cost them by # of new packages (we don't do that > sort of double-evaluation right now AFAIK just for optimisation, only for > discarded candidates?) > * Disregard the existing package because it would be an *older* PV, and we > could assume that's probably undesirable > * Change it so we don't apply this rule (prefer already-installed) if slots > are involved > * ??? > > BTW, this same issue came up with dev-lang/rust where it pulled in many old > dev-lang/rusts, even though dev-lang/rust-bin was first in the || ( ... ) > dep. I don't really know how dependencies evaluation works, but if it builds several version of dependencies trees to be merged, I'd suggest to inspect trees for the same found packages and prefer tree where exactly the same package version is reached in less number of steps. This should directly eliminate situation described in https://bugs.gentoo.org/show_bug.cgi?id=950310: if gcc-11 is required to build D language then use gcc-11 as direct dependency of gcc-14, instead of using a long chain with the same ending.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=cb1aac839eac339862b03704798e0b35b73cde56 commit cb1aac839eac339862b03704798e0b35b73cde56 Author: Alfred Wingate <parona@protonmail.com> AuthorDate: 2025-01-06 07:45:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-09 21:54:05 +0000 tests: resolver: Add xfail test for Ada bootstrap chain (bug #947587) Bug: https://bugs.gentoo.org/947587 Signed-off-by: Alfred Wingate <parona@protonmail.com> Signed-off-by: Sam James <sam@gentoo.org> lib/portage/tests/resolver/meson.build | 1 + lib/portage/tests/resolver/test_bootstrap_deps.py | 76 +++++++++++++++++++++++ 2 files changed, 77 insertions(+)
