First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 247370
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Portage team <dev-portage@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Vincent Legoll <vincent.legoll@gmail.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 247370 depends on: Show dependency tree
Bug 247370 blocks: 210077
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug

Description:   Opened: 2008-11-18 14:40 0000 
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

------- Comment #1 From Vincent Legoll 2008-11-18 14:42:25 0000 ------- 
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)

------- Comment #2 From Jeroen Roovers 2008-11-18 15:39:37 0000 ------- 
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).

------- Comment #3 From Vincent Legoll 2008-11-18 16:05:18 0000 ------- 
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...

------- Comment #4 From Zac Medico 2008-11-18 17:50:38 0000 ------- 
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.

------- Comment #5 From Zac Medico 2008-11-20 02:44:55 0000 ------- 
It's fixed in svn r12006 to share the code from bug #245231.

------- Comment #6 From Zac Medico 2008-11-22 05:55:49 0000 ------- 
This is fixed in 2.2_rc15.
First Last Prev Next    No search results available      Search page      Enter new bug