Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 230469 - portage --fetchonly should not wait for lockfiles
Summary: portage --fetchonly should not wait for lockfiles
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
Keywords: InVCS
Depends on:
Blocks: 216231
  Show dependency tree
Reported: 2008-07-02 07:05 UTC by Walter
Modified: 2010-10-06 21:22 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Walter 2008-07-02 07:05:51 UTC
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'!
Comment 1 Zac Medico gentoo-dev 2008-07-02 22:14:57 UTC
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.
Comment 2 Zac Medico gentoo-dev 2008-07-23 07:59:16 UTC
This is fixed in 2.2_rc2.