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? |
18 |
|
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. |
23 |
|
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. |
27 |
|
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. |
32 |
|
33 |
|
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. |
40 |
|
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. |
50 |
|
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. |
55 |
|
56 |
|
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. |
60 |
|
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. |
66 |
|
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 |