Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel
Date: Wed, 14 Apr 2010 06:12:25
Message-Id: 20100414061016.GA30025@hrair
In Reply to: Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel by "Michał Górny"
1 On Wed, Apr 14, 2010 at 07:45:20AM +0200, Michaaa GGGrny wrote:
2 > On Tue, 13 Apr 2010 19:12:08 -0700
3 > Zac Medico <zmedico@g.o> wrote:
4 >
5 > > Should we add a RESTRICT=parallel value for ebuilds that can't be
6 > > built at the same time as other ebuilds? Brian says we need it for
7 > > things like xorg-server which calls eselect opengl.
8 >
9 > I don't think that's the right solution. In most cases, xorg-server can
10 > be built in parallel with stuff which doesn't require/set specific
11 > opengl subsystem set.
13 RESTRICT=parallel is basically a big lock that forces building to go
14 down to one specific build/merge job- it's not at all fine grained.
15 That said, I'm not convinced it's worth actually *trying* to be fine
16 grained.
18 Stuff that needs this 'lock', if you look at it from the purely
19 academic angle is broken. The pkgs in question should be buildable
20 without modifying the livefs.
22 From the pragmatic angle, fixing some of those packages is a pretty
23 huge endeavour hence this lock existing. I see no reason to encourage
24 the usage of this lock by making it more fine grained, either.
28 > Well, in fact is there _really_ any package which won't work with
29 > switched opengl? I guess it's more of a runtime problem that buildtime,
30 > and I don't think we really should print out loudly 'libGL has been
31 > switched, please do not start OpenGL apps right now'.
33 Runtime and buildtime actually- consider a pkg that is mesa sensitive
34 having those headers/libs switched out mid build. That build likely
35 is going to boom in a rather interesting way.
37 Runtime itself, swapping out the gl resource that is used (going from
38 ati to x11 for building xorg-server) isn't going to make new apps that
39 start happy either.
42 > In fact, the best solution in this particular case would be to patch
43 > the buildsystem to use Gentoo location for particular OpenGL headers.
45 Academically, you're right, it's the proper solution. That takes a
46 fair amount of time however. More importantly, this issue *will* pop
47 up again elsewhere, meaning we'll have to delay the pkg in question
48 from being in the tree till it meets this higher QA standard.
50 Or we add this functionality, level the restrict, then go and fix the
51 ebuild- pragmatic solution.
54 > Disabling parallel emerge would be more of a workaround for the issue,
55 > and will influence much more packages than it needs to. And it won't
56 > help if user is running multiple emerge calls at the same time.
58 Running multiple emerges in parallel is already a bad idea. The
59 solution for that case is for the new/second emerge to feed the
60 request into the original emerge (or a daemon).
62 Keep in mind if support for multiple emerge invocations was
63 implemented it would still need some RESTRICT=parallel functionality
64 for screwed up pkgs like xorg-server. Fixing multiple emerge
65 invocations still requires fixing RESTRICT=parallel.
68 > Another possible workaround is to enable some kind of 'eselect opengl'
69 > locking so that another package requiring access to it will wait until
70 > our build finishes. But this, of course, would require a quite good
71 > solution for maintaining the lock and dropping it whenever build
72 > process is aborted/killed.
74 The other thing to recall is that by the time eselect is called, the
75 ebuilds environment may already be localized to settings that eselect
76 controls (LDPATH, that 'currently selected implementation' GL var).
77 My first thought is any locking scheme of that sort is going to be a
78 bigger can of worms.
80 ~brian