Bug 280038 – x11-base/xorg-server-1.6.2.901: ebuild modifies system OpenGL settings

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Martin von Gagern 2009-08-02 13:16:04 UTC]

The xorg-server ebuild does change the opengl setting in its setup function, but does not reset that value in case of a failed or intentionally partial build.

Steps to reproduce, on systems with nvidia drivers:
1. eselect opengl set nvidia
2. eselect opengl show
   nvidia
3. ebuild /usr/portage/x11-base/xorg-server/xorg-server-1.6.2.901.ebuild setup
   Switching to xorg-x11 OpenGL interface... done
4. eselect opengl show
   xorg-x11

I don't understand all the aspects involved. I'm not sure what modifications the eselect module does perform. I don't know what the --impl-headers switch actually does. I don't know why the xorg-server cares in the first place.

I do know, however, that I have repeatedly found my system mysteriously switched to xorg-x11 after using nvidia for long times, and that I could not reproduce those switches with updates to the nvidia drivers. I believe I now have the culprit identified: builds of xorg-server which failed to complete. This kind of modification can go unnoticed for long times, and as a change to opengl modules only takes effect when the X server is started, a bad configuration will force me to terminate my session, which is really annoying.

I also know that most ebuilds are written in such a way that they try not to modify the system outside their work directory. I have to concede that http://dev.gentoo.org/~gentoofan23/pms/eapi-2-approved/pms.html#x1-9400010.1.1 does indeed require full file system access for pkg_setup, but I still would value ebuilds if they would not tamper with the current configuration of a live system.

So my question is this: is there some way to avoid this hackery? Shouldn't it be possible to simply add -I/usr/lib/opengl/xorg-x11/include or equivalent to CPPFLAGS or some such in order to have the build use the xorg-x11 files no matter the glx configuration actually selected by the admin? Maybe the same for LD_LIBRARY_PATH, but that should cover everything, shouldn't it?

It would also be nice to find some comment in the ebuild why all this tweaking with the opengl implementation is required in the first place. I take it that those commands are currently there for a reason, and that they have been discussed somewhere. A pointer to said discussion would be nice. If portage were on some sane rcs, I might use blame or pickaxe to find the commit message corresponding to those lines, but with CVS I won't.

[Comment 1 James Earl Spahlinger 2009-08-09 23:30:18 UTC]

Please paste the output of 'emerge --info' into a bugzilla comment to assist the maintainers in resolving this issue

[Comment 2 Martin von Gagern 2009-08-10 07:46:40 UTC]

Created attachment 200794 [details]
emerge --info

(In reply to comment #1)
> Please paste the output of 'emerge --info' into a bugzilla comment to assist
> the maintainers in resolving this issue

Attached, but I'm pretty sure it contains no useful information about the issue at hand, which is the reason I didn't attach it in the first place.

[Comment 3 Rémi Cardona (RETIRED) 2009-08-14 08:38:10 UTC]

xorg-server needs to link against mesa's libGL and other libs, which eselect hides away from us.

The ebuild already switches back to nvida/fglrx at the end of the build phase. There's nothing we can do if the build ever fails.

There's only so much backwards-bending we can do for binary drivers...