Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [RFC] RESTRICT=parallel for builds that can't be executed in parallel
Date: Wed, 14 Apr 2010 09:04:30
Message-Id: 20100414090211.GB30025@hrair
In Reply to: [gentoo-dev] Re: [RFC] RESTRICT=parallel for builds that can't be executed in parallel by Duncan <>
1 On Wed, Apr 14, 2010 at 07:06:56AM +0000, Duncan wrote:
2 > Brian Harring posted on Tue, 13 Apr 2010 23:10:16 -0700 as excerpted:
3 >
4 > > RESTRICT=parallel is basically a big lock that forces building to go
5 > > down to one specific build/merge job- it's not at all fine grained. That
6 > > said, I'm not convinced it's worth actually *trying* to be fine grained.
7 > >
8 > > Stuff that needs this 'lock', if you look at it from the purely academic
9 > > angle is broken. The pkgs in question should be buildable without
10 > > modifying the livefs.
11 > >
12 > > From the pragmatic angle, fixing some of those packages is a pretty huge
13 > > endeavour hence this lock existing. I see no reason to encourage the
14 > > usage of this lock by making it more fine grained, either.
15 >
16 > What examples of the problem do we have, other than xorg-server due to
17 > eselect opengl?
19 Honestly it's the only hard class of examples I've got- ati-drivers
20 (presumably nvidia also although I've not checked) also would require
21 this. That said, 7 years of pkging crap, I know it's not going to be
22 the *only* example.
24 It mostly comes down the perfect world view vs pragmatic- a lot of
25 what we're doing in terms of ebuild pkging is a balance between best
26 practice and having the thing usable.
28 Sometimes you've got to do something ugly to make it work- especially
29 when the effort required to do it correctly is fairly large. I'm not
30 arguing against doing it correctly, I'm just arguing we should be
31 realistic.
34 > For just xorg-server, killing parallel seems like a rather frustrating and
35 > indeed broken solution (especially for folks who prefer to run freedomware
36 > and thus have only the X11/mesa opengl version on their system anyway, so
37 > forcing non-parallel is an exercise in uselessness). If it's the only
38 > one, at /least/ only forcing non-parallel if the eselect opengl actually
39 > changes the selected opengl would seem reasonable.
41 The thing people need to keep in mind for stuff like this is that
42 metadata is *constant*- it's quite a huge amount of work to write a
43 framework that is able to ask "hey xorg, are you going to go screwing
44 w/ something that means we can't build something in parallel to you
45 building?"- it's not horrible, but it's a lot of effort for
46 questionable gain. If you consider users running ati-drivers, that
47 check would state "yes, lock it" for building both ati-drivers and
48 xorg-server; the only instance where it wouldn't trigger the lock is
49 when the user is running *just* xorg-server.
51 Also, just to be clear, RESTRICT=parallel does not means that building
52 xorg-server is going to be make -j1; it can still be make -jN, it just
53 keeps the scheduler from building any other jobs in parallel while
54 xorg-server is doing it's thing.
57 > But if there's other non-contrived examples around, getting a couple of
58 > them on the table should I think clarify our potential usage constraints
59 > somewhat.
61 As mentioned, I've got nothing else concrete- mostly because I've not
62 had the time to look (I do know they're going to be there however).
63 One thing to keep in mind also is that when situations of this sort
64 pop up we need the functionality *before* it occurs. Adding it after
65 the fact is a PITA.
67 What I'd like to see w/ RESTRICT=parallel is that it basically is
68 unused in the tree- I expect a few screwed up pkgs to need it however.
69 It's a bit like RESTRICT=sandbox; it should only be used when there is
70 an extremely good reason and the alternatives don't easily exist.
71 ~harring