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
pgpElSBoLr8iw.pgp
Description: PGP signature
