Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Simultaneously emerging multiple packages with same dependencies
Date: Thu, 27 Jan 2011 13:13:50
Message-Id: 4D416F12.8000202@gmail.com
In Reply to: Re: [gentoo-user] Re: Simultaneously emerging multiple packages with same dependencies by Neil Bothwick
1 Neil Bothwick wrote:
2 > On Thu, 27 Jan 2011 07:12:24 +0200, Nikos Chantziaras wrote:
3 >
4 >
5 >>> I'm aware that portage uses locking mechanism before modifying 'world'
6 >>> file, but what about the actual building process ? I'd expect emerge
7 >>> to check if dependency package is already build/installed (or
8 >>> currently being build by another instance) and just skip it in this
9 >>> case, however I haven't tried it yet.. Can anybody shred some light
10 >>> on this ?
11 >>>
12 >> You can try, but the second instance with simply block until the lock
13 >> has been removed.
14 >>
15 > The lock is not there for the entire emerge, I have run two emerges at
16 > the same time, such as when I needed to install something while a world
17 > update is in progress. It is possible, but not recommended as a general
18 > strategy. That's what --jobs is for.
19 >
20 >
21 >
22
23 I have done the same thing and as long as the dependencies don't clash,
24 it works fine. However, if you start one emerge with a set of
25 dependencies, then start another and they clash somewhere in the middle,
26 portage has issues. That is where the locks would kick in I guess. I
27 would also imagine that portage could emerge the same package twice
28 too. If one instance of emerge doesn't know what the other instance has
29 already done, then the second one could emerge it again. Doesn't emerge
30 do all the calculating at the beginning and runs with that until the end?
31
32 I am using the -j option for the first time now. I'm updating KDE. It
33 seems to work fine. It doesn't scroll all the stuff like with a regular
34 emerges but this new rig is so fast, I can't read it anyway. I did have
35 a package to fail and it spit out the error for me to read.
36
37 I agree, using --jobs is the best way to do this. It works really well
38 if you have a fast multi-core CPU. I wish I had got me a 6 core one
39 now. ;-)
40
41 Dale
42
43 :-) :-)

Replies