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

[Andreas Beckmann]

[adding pkg-fglrx-devel@ to the discussion]

On 2011-07-22 21:12, Cyril Brulebois wrote:
> Julien Cristau <jcristau at debian.org> (22/07/2011):
>> So in principle I dislike the idea of making the mesa packages messier
>> to make the closed driver packages' life easier.  One thing that's been
>> a source of countless bug in the current system is diversions, because
>> they're evil, and people keep getting them wrong, and users don't
>> understand/expect them, and all kinds of fun ensues.  If mesa were to
>> not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but
>> instead ship an alternative itself, would that be enough to put an end
>> to the diversions?  Not that I think alternatives are ideal either, but
>> if we're going to have to put up with something I'd rather it wasn't
>> *both* alternatives and diversions.
>>
>> Not sure what other X people think.
> 
> I'd rather avoid the mess of diversions *AND* alternatives indeed. If
> adding alternative support to mesa is the price to pay, I guess we could
> work something out.

OK, that is a different solution that should simplify this even more.

What is the correct approach to do alternatives of libraries in
Multi-Arch: yes packages?
* a separate alternative for each architecture (allows weird mixed
configurations)
* one alternative (from an extra Multi-Arch: foreign package) that
covers all arches as slaves links?
* the Ubuntu approach of dropping something in ld.so.conf.d/ - would we
need one file/one alternative per arch? (I didn't look in detail at the
Ubuntu packages, yet.) A gain handling config files with alternatives
... but this time config files that are not meant for user modification
(compared to my approach to handle xorg.conf or xorg.conf.d/nvidia.conf
with alternatives)

libGL.so.1 is not the only file to be diverted, libglx.so is being
replaced by the vendors drivers, too. Or is there some way of "search
path magic" that would allow to place the "higher priority alternative"
in a different location where it would be picked up before
/usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
the diversion here. Something similar to /lib/modules/*/updates/ ...

Andreas