yey! Great. ls, cp and all will fail due to linking with acl even though theres no dependancy. configure automagic galore, this breaks binary installs.
spider, huh?
Ughm, sorry, This was a fluke of my brain ;) the problem seems to be somwhere, but I haven't been able to trace it. Let me describe: from a clean stage3'ish (old one) system, mounting up the binary packages on /usr/portage/packages; emerge -kvp coreutils; will show attr, acl and ncurses for installing. However when pointing PORTAGE_BINHOST to the same binaries and doing "emerge -gvp coreutils", suddenly attr+acl aren't downloaded/installed and one is left with a system without cp/ls and company. Generic pain in the nether regions
dammit, Cant reproduce this on my own systems, even though I had to help somone with it last night. annoying. resolving as needinfo until I find out wtf went wrong
okay! I got this one nailed down. portage version : bash-2.05b# emerge --version Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.23) (really, its -r21 according to the database) Normally: bash-2.05b# USE="-acl" emerge -vkp coreutils [binary N ] sys-apps/attr-2.4.7-r1 +nls -debug [binary N ] sys-apps/acl-2.2.13-r1 [binary U ] sys-libs/ncurses-5.3-r5 [5.3-r2] -debug [binary U ] sys-apps/coreutils-5.0.91-r4 [5.0-r3] +nls -build -acl -selinux -static bash-2.05b# USE="-acl" emerge -vkp system |grep acl [binary U ] sys-apps/coreutils-5.0.91-r4 [5.0-r3] +nls -build -acl -selinux -static So, the "real" dependencies aren't tracked when using "system" as a target.!
bash-2.05b# USE="-acl" emerge -vkp coreutils |grep acl [binary N ] sys-apps/acl-2.2.13-r1 [binary U ] sys-apps/coreutils-5.0.91-r4 [5.0-r3] +acl -build +nls -(selinux) -static bash-2.05b# USE="-acl" emerge -vkp system |grep acl [binary U ] sys-apps/coreutils-5.0.91-r4 [5.0-r3] -acl -build +nls -(selinux) -static bash-2.05b# emerge --version Portage 2.0.50 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.23)
Created attachment 25120 [details, diff] Fix for incorrect USE flags with binpkgs on emerge system Couldn't find exactly what causes the problem, but it is something to do with select_dep not calling itself. Put simply, this patch removes the separate processing of system/world packages and instead uses the same processing as if they were all specified on the command line. Minimal testing but seems to work with no problems and no slow down.
Created attachment 25127 [details, diff] Alternative Fix This patch fixes the bug with the original logic. Personally, I prefer the former first patch as it means that similar functionality doesn't need to be maintained in two places.
Used the second one. That area of code reports back missing binary packages to the user... It's different than the other accounting.
Bug has been fixed and released in stable portages on or before 2.0.51-r2
