I'm using sys-apps/portage-2.1.10.11 on a ~x86 system but i've seen it on most (all) my other gentoo boxes (i got ~7 of them, mostly ~amd64, but also ~x86 and x86). I think the problem is related to the '-j' option for emerge here's an example showing the problem. The command was emerge -vtaq --keep-going -j 2 --load-average=3 -u system The output is: ... Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 35) app-arch/xz-utils-5.0.3 >>> Emerging (2 of 35) sys-devel/gnuconfig-20110814 >>> Emerging (3 of 35) virtual/man-0 >>> Emerging (4 of 35) sys-libs/e2fsprogs-libs-1.41.14 >>> Emerging (5 of 35) sys-libs/ncurses-5.9 >>> Emerging (6 of 35) sys-apps/grep-2.9 >>> Emerging (7 of 35) sys-apps/kbd-1.15.3 >>> Emerging (8 of 35) sys-apps/busybox-1.18.5 >>> Emerging (9 of 35) sys-apps/gawk-4.0.0 >>> Emerging (10 of 35) app-arch/bzip2-1.0.6-r3 >>> Emerging (11 of 35) app-arch/tar-1.26 >>> Emerging (12 of 35) virtual/package-manager-0 >>> Emerging (13 of 35) net-misc/rsync-3.0.8 The problem is that nothing got installed. The usual behavior is to display "Emerging xxx", and later on "installing xxx". If using -jx, this is mixed, but it's ok. I've checked the files /tmp/portage/*/*/temp/build.log. And here is what i think happens: Portage uncompress/config and compiles packages, run the 'make install' step. And that's it, it does not do the "install on actual location and record this in portage database" ( i dont know the name of this step). The -j2 is respected, in the sense that never more than two packages are being compiled/installed. I've used tail -f on all those files to check. I've also checked using 'genlop xxx' to see if by change the package was installed nonetheless, but the output doesn't show the date of today. Eventually, all packages got installed, but this can go very long (this is why i dont have a whole exemple to show, it's already 'emerging' it's 18th package with nothing installed yet. This is especially annoying on low-end system where you can not stop portage (^c) because you would loose all packages compiled, but not yet installed. From my point of view it's a "major feature is broken", but i guess i'll let you decide on the severity. I can be reached as 'orzel' on irc if you want. Reproducible: Always
I did another check: pstree. It also shows that only two packages are being worked on. I dont know if the paste will display clearly : you can see my ssh sessioni with bash and emerge. Emerge has two children 'sandbox', each one with ebuild.sh... and so on. │ ├─sshd(2492)───bash(2501)───emerge(12504)─┬─sandbox(6647)───ebuild.sh(6648)───ebuild.sh(6670)───configure(6686)───configure(19657) │ │ └─sandbox(17546)───ebuild.sh(17551)───ebuild.sh(17575)───emake(17594)───make(17595)───sh(17615)───sh(17
From the FAQ located at http://www.gentoo.org/proj/en/portage/doc/faq.xml: Q: When packages are built in parallel with the --jobs option, why aren't some packages installed immediately after they have finished building? They are installed only after a long delay. A: As a safety precaution, installation actions for system packages and their deep dependecies are executed only when no other packages are building. This behavior is required in order to avoid cases like bug 256616 (unspecified system dependencies) and bug 259954 (temporarily unsatisfied system dependencies).
ok, i did not know, my fault. I have not checked the FAQ for a long time. This decision has huge impacts. For example in term of hard disk requirements ~35 times bigger (in my example) and making ^C impossible. A solution could be to have at least an 'install point' every few packages or whatever, but i understand it is not a trivial task, and no, i'm not volunteering to do it. Any way, the FAQ makes it clear the bug is not considered a bug, i'm closing it. Sorry again for the false report.
(In reply to comment #3) > ok, i did not know, my fault. I have not checked the FAQ for a long time. This > decision has huge impacts. For example in term of hard disk requirements ~35 > times bigger (in my example) and making ^C impossible. You can always use --jobs=1 to avoid the behavior. > A solution could be to have at least an 'install point' every few packages or > whatever, but i understand it is not a trivial task, and no, i'm not > volunteering to do it. Yeah, we could add an option for that. We could also add an option to disable the scheduling tweaks from bug 256616.
