portage locking prevents parallel fetching of distfiles. SPECULATION: Maybe the locking should occur on the distfiles instead of the packages themselves, and only after the checksums or actual file presence is confirmed to be wrong. Reproducible: Always Steps to Reproduce: 1.emerge -DN world in one window 2. emerge -DNf in another, this one is waiting for lock files of packages that are currently being built, this should not happen. Actual Results: the emerge -DNf wait for locks to be released on packages that are already present Expected Results: the fetchonly should skip the files that are already there
emerge --version Portage 2.2_rc14 (default/linux/amd64/2008.0, gcc-4.2.4, glibc-2.8_p20080602-r0, 2.6.27.4 x86_64)
Looks like an unusual test to me - AFAIK having parallel emerge processes isn't the same as having parallel subprocesses (and I surely have seen some weird behaviour running parallel emerge calls that I wouldn't want to blame sys-apps/portage for).
Maybe this will become a "wont fix" but this had been working smoothly for ages and broke recently... and as it is annoying me, I wanted to report the problem...
This case is similar to bug 245231. Like that case, it makes sense to create a separate temporary directory for --fetchonly mode. However, I'm curious about why you run a separate emerge instance for fetching. That's supposed to be what FEATURES=parallel-fetch is for. It's enabled by default now, and /var/log/emerge-fetch.log should show the output so you can see that it's working. In the future I'd like to add support for something like --jobs that's for parallel fetching instead of parallel building, which will allow you to control the number of fetches that will be automatically performed in parallel. It could be called --fetch-jobs.
It's fixed in svn r12006 to share the code from bug #245231.
This is fixed in 2.2_rc15.
