implement gles-alternatives like glx-alternatives

[Andreas Beckmann]

On 2011-07-16 22:26, Heiko Stübner wrote:
> Hi,
> 
> glx-alternatives provides the means to have more than one libGL and glx 
> implementation on a machine.
> 
> I'm working on the Toshiba AC100 (NVidia Tegra ARM SoC) which also got a 
> proprietary driver released two weeks ago [1].
> 
> Tegra, like Omap, and probably other SoCs support "only" OpenGL ES (1 and 2) 
> wich is also provided by Mesa libs.
> 
> So I was wondering what would be the best way to realise a diversion system 
> like glx-alternatives for the OpenGL ES stuff.

I think we should include the MESA packagers to see how they intended to
make glx/gles and vendor implementations working together (I do know
nothing about egl/gles).
Please repost your question (and my comments below and eventual answers
to them) including debian-x at lists.debian.org in the Cc:

> Possibilities I came up with were:
> - build a completely separate gles-alternatives source package realising the 
> same functionality like glx-alternatives
Is there any library (and diversion) overlap between glx and gles?
yes -> merge with glx-diversions
no -> separate packages (but eventually still the same source package
for better code sharing)

> - let glx-alternatives also build packages for handling OpenGL ES stuff.
Would be a possibility.

> Libs that need to be diverted most of the time are libEGL.so.1, 
> libGLESv1_CM.so.1 and libGLESv2.so.2 (at least for Tegra and Omap4[2] ).

Is libEGL.so.1.0 (from package libegl1-mesa) a "fixed" filename or is it
expected to be changed regularily? (libGL.so.1.2 from libgl1-mesa-glx is
"fixed", but libgl1-mesa-swx11 provides libGL.so.5.* which changes with
each upstream version and is therefore not divertible).
Same question for the other libraries.

Andreas