User:ManDay/Deprecating the virtual OpenGL ebuild

This page discusses the resolution of bug #890334

Current situation and historical context

Packages which want to use Khronos' OpenGL rendering API also need an API for creating a rendering context in the windowing system. The API for creating a rendering context specifically for X11 is called GLX and another, more generic API for Wayland and other windowing systems is called EGL.

Historically, Mesa provided its implementation of OpenGL and GLX in a single library called libGL. Since the OpenGL functionality was thereby glued to X11 functionality, it was either libGL with OpenGL and GLX - and therefore dependence on X11 libraries - or nothing. There was no support for (full) OpenGL on X11-free systems, such as those running pure Wayland.

Since the emergence of libglvnd, an abstraction to provide OpenGL regardless of which implementation - such as Mesa - runs behind it, this is no longer true. OpenGL and GLX are now provided though libglvnd's abstraction as separate pieces, called libOpenGL and libGLX, respectively.

Resulting problems

1. Currently, many packages which require in any, nonspecific way OpenGL or GLX depend on virtual/opengl without finer distinction. virtual/opengl, to satisfy all possible combinations, therefore pulls in media-libs/mesa[X] to guarantee the availability of GLX but, on the downside, requires X11, although it is often not needed.
2. Further, virtual/opengl's original purpose to abstract away different OpenGL implementations is deprecated by libglvnd, which also extends to the abstraction of GLX, EGL, and GLES.

Note
Currently, support for GLES or EGL can not be configured on media-libs/libglvnd

Resolution

Both problems can be adressed simultaneously. virtual/opengl as a non-configurable middleman will be depreated in favour of depending on media-libs/libglvnd, which can be configured through USE-flags according to the depender's need of OpenGL, GLES, GLX, and EGL.

What should I do if my ebuild depends on virtual/opengl?

If your ebuild depends on virtual/opengl it does so because of the historically more correct reasons of needing an OpenGL component such as OpenGL itself or GLX, or because of the historically less correct reasons of needing another component which was coincidentally pulled in through virtual/opengl, but not strictly related, such as Mesa's libgbm.

To choose the correct dependencies for your ebuild...

1. Determine against which OpenGL libraries the software in your ebuild is linked and depend on media-libs/libglvnd accordingly. If you do not know this off hand, you can use ldd (from sys-libs/glibc), scanelf -n or lddtree (from app-misc/pax-utils).
   • libGL or possibly libGLX → media-libs/libglvnd[X]
   • libOpenGL → media-libs/libglvnd
2. If your ebuild can be configured for with or without support for X, reflect the USE-Flag conditionally, e.g. media-libs/libglvnd[X?].
3. Determine if there are hidden dependencies on unrelated libraries which were previously coincidentally provided and depend on the correct provider. Plausible candidates include
   • libgbm → media-libs/mesa
4. Remove the dependency on virtual/opengl

Warning
If support for X can be configured, still make sure that the sofware links correctly; sometimes the source expects linkage against X libraries even though no support for X is set during the configure phase!