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

[Julien Cristau]

On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote:

> 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)
> 
Pretty please not messing with ld.so.conf.

> 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/ ...
> 
That shouldn't be too hard.

Cheers,
Julien