[RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations

[Andreas Beckmann]

Hi,

currently there are multiple vendor implementations for
libGL.so.1/libglx.so and soon there will be vendor implementations for
libEGL.so.1/libGLES*.so.*, too.
The GL part is currently being handled by diversions and alternatives,
and the upcoming EGL part is planning to do this similar.
Unfortunately the diversions require quite some knowledge about the
files shipped by the MESA packages.
Therefore I suggest the following new layout to be used by the MESA
packages to simplify diversions and alternatives:

/usr/lib[/<triplet>]/mesa:
  libFOO.so.1.2.3
  libFOO.so.1 -> libFOO.so.1.2.3
  libFOO.so -> libFOO.so.1

/usr/lib[/<triplet>]:
  libFOO.so.1 -> mesa/libFOO.so.1
  libFOO.so -> mesa/libFOO.so

(for appropriate substitutions of FOO, .1$ , .1.2.3$)

Behind this are the following ideas:

* move the real file (libFOO.so.1.2.3) out of the scope of ldconfig
(which could mess up the SONAME link otherwise)
* simplify diverting the libraries: one only needs to know the SONAME
(libFOO.so.1) but not the real filename (libFOO.so.1.2.3) which is
allowed to change (e.g. libgl1-mesa-swx11 changes the filename with each
new upstream release, so it's currently not divertible)
* only one diversion per library is needed
(/usr/lib[/<triplet>]/libFOO.so.1) instead of three (libFOO.so.1.2.3,
libFOO.so.1, libFOO.so)
* the libFOO.so link is not affected by a diversion of libFOO.so.1 -
which aides the following behaviour: link with the free mesa library
when building the application, but use the accelerated vendor library
when running the application
* mesa can be provided as a more obvious alternative /usr/lib/mesa

I wouldn't limit the new approach to a few architectures (amd64 and i386
need it right now, armel will need it for EGL, soon), as we don't know
where vendors will provide custom implementations in the future.

I can create a patch for the mesa packages in case someone is interested.


Andreas