On Wed, Apr 14, 2010 at 07:45:20AM +0200, Michaaa GGGrny wrote: > On Tue, 13 Apr 2010 19:12:08 -0700 > Zac Medico <zmed...@gentoo.org> 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
pgpObsKog41jr.pgp
Description: PGP signature
