Since both opengl-update and eselect-opengl provide gl(x)ext.h as well as the same functionality, they really ought to block each other. However, all versions of xorg-x11 currently in Portage depend on opengl-update when USE=opengl, and all the latest revisions of all versions of nvidia-glx depend on xorg-x11 and eselect-opengl. Having the two block each other would make it effectively impossible to install nvidia-glx. Either xorg-x11 would have to be moved to eselect-opengl, or nvidia-glx would have to be moved back to opengl-update. I'm sure similar issues would exist in ati-drivers and possibly others. Please be careful when fixing this. If, for example, opengl-update was the last merged and gets removed in a depclean or updated to no longer include the headers, then the system will be left without a gl(x)ext.h. I don't think anyone wants a bunch of bug reports by users who can no longer build apps that use opengl extensions. ;)
This probably requires a little discussion... eselect stuff is still ~, so this doesn't affect the stable tree. When will eselect-opengl be moved to stable?
uhm, this doesn't affect the ~arch tree either as opengl-update depends on eselect-opengl to provide all that, and it just provides a wrapper. opengl-update-3.0 will go stable at the same time eselect-opengl does which will depend on when eselect goes stable. I have no control over that.
Sorry, I forgot I had the nvidia and eselect stuff in package.keywords, but not opengl-update. opengl-update-3.0.0 resolves the issue. A block on <opengl-update-3 for eselect-opengl might still be in order though. It would avoid pointless bugs like this in the future. :|
