If package A has a := dependency on package B, then when B is scheduled for upgrade, is it valid for Portage to rebuild A before upgrading B?
I'm hitting this case on a couple of my machines, with the perl 5.30.3 to 5.32.1 upgrade. When I run 'emerge -puvDU @world', Portage wants to rebuild several dev-perl/* and virtual/perl-* packages [rR] before building dev-lang/perl [rU]. At best, the initial rebuilds look redundant, but this disagrees with how I understand subslot rebuilds to work.
A section of the emerge pretend output is as follows, the full log is attached:
> ... (53 other packages, mostly perl things) ...
> [ebuild rR ] dev-perl/TimeDate-2.330.0::gentoo 0 KiB
> [ebuild rR ] perl-core/File-Temp-0.230.900::gentoo 74 KiB
> [ebuild U ] dev-perl/Digest-HMAC-1.30.0-r2::gentoo [1.30.0-r1::gentoo] 0 KiB
> [ebuild U ] sys-devel/automake-1.16.3-r1:1.16::gentoo [1.16.2-r1:1.16::gentoo] USE="-test" 1,554 KiB
> [ebuild rR ] dev-perl/Module-Build-0.422.400::gentoo USE="-test" 298 KiB
> [ebuild rR ] dev-perl/Locale-gettext-1.70.0::gentoo 9 KiB
> [ebuild r U ] dev-lang/perl-5.32.1:0/5.32::gentoo [5.30.3:0/5.30::gentoo] USE="berkdb gdbm -debug -doc -ithreads -minimal%" 12,442 KiB
> [ebuild U ] dev-vcs/git-2.31.1::gentoo [2.26.3::gentoo] USE="blksha1 curl emacs gpg iconv nls pcre perl threads tk webdav -cgi -cvs -doc -gnome-keyring -highlight -mediawiki -mediawiki-experimental -perforce (-ppcsha1) -subversion -test -xinetd (-pcre-jit%*)" PYTHON_SINGLE_TARGET="python3_8 -python3_7 -python3_9%" 6,740 KiB
> [ebuild rR ] dev-perl/IPC-System-Simple-1.250.0::gentoo USE="-test" 0 KiB
> The following packages are causing rebuilds:
> (dev-lang/perl-5.32.1:0/5.32::gentoo, ebuild scheduled for merge) causes rebuilds for:
> (dev-perl/Locale-gettext-1.70.0:0/0::gentoo, ebuild scheduled for merge)
dev-lang/perl-5.32.1 has PDEPEND on some virtual/perl-* packages, but at least I don't see why Locale-gettext couldn't be built after perl.
Portage wanted to do this on two of three of my machines. On one where I went ahead with the world upgrade, the upgrade went smoothly, though a subsequent 'emerge -puvDU @world' now wants to rebuild those too-early packages again.
On the remaining machine, disabling dynamic deps and adding --changed-deps=y doesn't change the build plan. Portage reports that libxml2 can't be updated due to dependency constraints, not sure if that's related. I'm happy to post the compressed 'emerge --debug' log if that'll help, it's 1.7M.
Or maybe this is just a corner case that Portage is handling correctly?
Created attachment 713379 [details]
Created attachment 713382 [details]
emerge -puvDU @world
Things like this are triggered by bug 756199.