[RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations
Julien Cristau
jcristau at debian.org
Mon Jul 25 17:03:38 UTC 2011
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
More information about the pkg-nvidia-devel
mailing list