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

[Brian Harring]

On Wed, Apr 14, 2010 at 07:45:20AM +0200, Michaaa GGGrny wrote:
> On Tue, 13 Apr 2010 19:12:08 -0700
> Zac Medico <zmedico@g.o> wrote:
>
> > Should we add a RESTRICT=parallel value for ebuilds that can't be
> > built at the same time as other ebuilds? Brian says we need it for
> > things like xorg-server which calls eselect opengl.
>
> I don't think that's the right solution. In most cases, xorg-server can
> be built in parallel with stuff which doesn't require/set specific
> opengl subsystem set.

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.



> Well, in fact is there _really_ any package which won't work with
> switched opengl? I guess it's more of a runtime problem that buildtime,
> and I don't think we really should print out loudly 'libGL has been
> switched, please do not start OpenGL apps right now'.

Runtime and buildtime actually- consider a pkg that is mesa sensitive 
having those headers/libs switched out mid build.  That build likely 
is going to boom in a rather interesting way.

Runtime itself, swapping out the gl resource that is used (going from 
ati to x11 for building xorg-server) isn't going to make new apps that 
start happy either.


> In fact, the best solution in this particular case would be to patch
> the buildsystem to use Gentoo location for particular OpenGL headers.

Academically, you're right, it's the proper solution.  That takes a 
fair amount of time however.  More importantly, this issue *will* pop 
up again elsewhere, meaning we'll have to delay the pkg in question 
from being in the tree till it meets this higher QA standard.

Or we add this functionality, level the restrict, then go and fix the 
ebuild- pragmatic solution.


> Disabling parallel emerge would be more of a workaround for the issue,
> and will influence much more packages than it needs to. And it won't
> help if user is running multiple emerge calls at the same time.

Running multiple emerges in parallel is already a bad idea.  The 
solution for that case is for the new/second emerge to feed the 
request into the original emerge (or a daemon).

Keep in mind if support for multiple emerge invocations was 
implemented it would still need some RESTRICT=parallel functionality 
for screwed up pkgs like xorg-server.  Fixing multiple emerge 
invocations still requires fixing RESTRICT=parallel.


> Another possible workaround is to enable some kind of 'eselect opengl'
> locking so that another package requiring access to it will wait until
> our build finishes.  But this, of course, would require a quite good
> solution for maintaining the lock and dropping it whenever build
> process is aborted/killed.

The other thing to recall is that by the time eselect is called, the 
ebuilds environment may already be localized to settings that eselect 
controls (LDPATH, that 'currently selected implementation' GL var).  
My first thought is any locking scheme of that sort is going to be a 
bigger can of worms.

~brian