Portage should not wait for lockfiles when run in --fetchonly mode I understand that fetching the same package in parallel might be a bad idea, however this could be resolved by checking to see if the file is currently open (lsof style) or by using a package-version.tar.gz.lock file with the PID for the portage process (allowing auto detection/removal of old or dead locks). Reproducible: Always Steps to Reproduce: 1. emerge gnome (in one VT) 2. emerge --fetchonly mysql (in another VT) Actual Results: during some gnome package compile (actual compile process), emerge --fetchonly mysql is forced to wait Expected Results: emerge gets fetchin'!
The file lock is required once it makes the decision to download. However, we can make it skip the current file if that file happens to be locked by another process. This could be implemented by adding a new parameter to the portage.locks.lock() function which causes it to raise an exception if the file is already locked. This will give the caller an opportunity to decide not to acquire a lock on a file that is already locked. The --fetch code can simply handle the exception and move on to the next file.
This is fixed in 2.2_rc2.
