Rebuild is not triggered with RDEPEND="|| ( other_package some_package:= )" and --dynamic-deps=n. some_package is installed. other_package is not installed. Problem does not occur when some_package:= is first in || ( ). It is irrelevant if := was appended to other_package. # cat app-misc/A/A-1.ebuild EAPI="5" SLOT="0/1" KEYWORDS="*" # cat app-misc/A/A-2.ebuild EAPI="5" SLOT="0/2" KEYWORDS="*" # cat app-misc/B/B-0.ebuild EAPI="5" SLOT="0" KEYWORDS="*" RDEPEND="app-misc/A:=" # cat app-misc/C/C-0.ebuild EAPI="5" SLOT="0" KEYWORDS="*" RDEPEND="|| ( app-misc/X app-misc/A:= )" # emerge -1 =app-misc/A-1 ... # emerge app-misc/{B,C} ... # cat /var/db/pkg/app-misc/C-0/RDEPEND || ( app-misc/X app-misc/A:0/1= ) # emerge -ptv --dynamic-deps=y app-misc/A These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild rR ] app-misc/C-0::local 0 KiB [ebuild rR ] app-misc/B-0::local 0 KiB [ebuild r U ] app-misc/A-2:0/2::local [1:0/1::local] 0 KiB Total: 3 packages (1 upgrade, 2 reinstalls), Size of downloads: 0 KiB The following packages are causing rebuilds: (app-misc/A-2:0/2::local, ebuild scheduled for merge) causes rebuilds for: (app-misc/B-0:0/0::local, ebuild scheduled for merge) (app-misc/C-0:0/0::local, ebuild scheduled for merge) # emerge -ptv --dynamic-deps=n app-misc/A These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild rR ] app-misc/B-0::local 0 KiB [ebuild r U ] app-misc/A-2:0/2::local [1:0/1::local] 0 KiB Total: 2 packages (1 upgrade, 1 reinstall), Size of downloads: 0 KiB The following packages are causing rebuilds: (app-misc/A-2:0/2::local, ebuild scheduled for merge) causes rebuilds for: (app-misc/B-0:0/0::local, ebuild scheduled for merge)
Use of := within || is self-contradictory, meaningless and forbidden. Patch for repoman check will be appreciated.
(In reply to Michał Górny from comment #1) > Use of := within || is self-contradictory, meaningless and forbidden. Sure, but since app-misc/X is not installed, it suggests that this test case may represent an opportunity to improve our || dep handling for other cases that are not forbidden. So, I'd like to re-open this bug for further investigation.
There's a working test case here: https://github.com/zmedico/portage/commits/bug_522652 The debug log shows it select X. Parent: (app-misc/C-0:0/0::test_repo, installed) Depstring: || ( app-misc/X app-misc/A:0/1= ) Priority: runtime Candidates: ['app-misc/X'] The unsatisfied app-misc/X dependency is placed in _initially_unsatisfied_deps and ignored. I will work on creating a similar test case that does not involve any forbidden || ( bar foo:= ) usage. For example, this wouldn't be forbidden: || ( app-misc/X <app-misc/A-2 )
(In reply to Zac Medico from comment #3) > I will work on creating a similar test case that does not involve any > forbidden || ( bar foo:= ) usage. For example, this wouldn't be forbidden: > > || ( app-misc/X <app-misc/A-2 ) In my bug_522652 branch on github, there's a modified version of the previous test, using the above deps that are not forbidden. It demonstrates similar undesirable behavior that we can fix (dep_zapdeps is at fault).
Created attachment 384644 [details, diff] dep_zapdeps: fix bug #522652 For cases such as || ( X <A-2 ), where X is unsatisfiable and A-1 is installed, fix dep_zapdeps to make the correct choice. I've split the || ( X A:= ) test case into a separate patch which is in this branch: https://github.com/zmedico/portage/tree/bug_522652
This is in git for the 2.2.13 release: https://github.com/gentoo/portage/commit/d1e8d3468d0cee24480f6cbe16b2ca82ec7dc9fa https://github.com/gentoo/portage/commit/4fcf4fa56c0033d726eb0755e3ca67b3337ad944
This is fixed in 2.2.13.