Re: [gentoo-dev] Re: [RFC] RESTRICT=parallel for builds that can't be executed in parallel

[Brian Harring]

On Wed, Apr 14, 2010 at 07:06:56AM +0000, Duncan wrote:
> Brian Harring posted on Tue, 13 Apr 2010 23:10:16 -0700 as excerpted:
>
> > RESTRICT=parallel is basically a big lock that forces building to go
> > down to one specific build/merge job- it's not at all fine grained. That
> > said, I'm not convinced it's worth actually *trying* to be fine grained.
> >
> > Stuff that needs this 'lock', if you look at it from the purely academic
> > angle is broken.  The pkgs in question should be buildable without
> > modifying the livefs.
> >
> > From the pragmatic angle, fixing some of those packages is a pretty huge
> > endeavour hence this lock existing.  I see no reason to encourage the
> > usage of this lock by making it more fine grained, either.
>
> What examples of the problem do we have, other than xorg-server due to
> eselect opengl?

Honestly it's the only hard class of examples I've got- ati-drivers 
(presumably nvidia also although I've not checked) also would require 
this.  That said, 7 years of pkging crap, I know it's not going to be 
the *only* example.

It mostly comes down the perfect world view vs pragmatic- a lot of 
what we're doing in terms of ebuild pkging is a balance between best 
practice and having the thing usable.

Sometimes you've got to do something ugly to make it work- especially 
when the effort required to do it correctly is fairly large.  I'm not 
arguing against doing it correctly, I'm just arguing we should be 
realistic.


> For just xorg-server, killing parallel seems like a rather frustrating and
> indeed broken solution (especially for folks who prefer to run freedomware
> and thus have only the X11/mesa opengl version on their system anyway, so
> forcing non-parallel is an exercise in uselessness).  If it's the only
> one, at /least/ only forcing non-parallel if the eselect opengl actually
> changes the selected opengl would seem reasonable.

The thing people need to keep in mind for stuff like this is that 
metadata is *constant*- it's quite a huge amount of work to write a 
framework that is able to ask "hey xorg, are you going to go screwing 
w/ something that means we can't build something in parallel to you 
building?"- it's not horrible, but it's a lot of effort for 
questionable gain.  If you consider users running ati-drivers, that 
check would state "yes, lock it" for building both ati-drivers and 
xorg-server; the only instance where it wouldn't trigger the lock is 
when the user is running *just* xorg-server.

Also, just to be clear, RESTRICT=parallel does not means that building 
xorg-server is going to be make -j1; it can still be make -jN, it just 
keeps the scheduler from building any other jobs in parallel while 
xorg-server is doing it's thing.


> But if there's other non-contrived examples around, getting a couple of
> them on the table should I think clarify our potential usage constraints
> somewhat.

As mentioned, I've got nothing else concrete- mostly because I've not 
had the time to look (I do know they're going to be there however).  
One thing to keep in mind also is that when situations of this sort 
pop up we need the functionality *before* it occurs.  Adding it after 
the fact is a PITA.

What I'd like to see w/ RESTRICT=parallel is that it basically is 
unused in the tree- I expect a few screwed up pkgs to need it however.  
It's a bit like RESTRICT=sandbox; it should only be used when there is 
an extremely good reason and the alternatives don't easily exist.
~harring