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

Andreas Beckmann debian at abeckmann.de
Mon Oct 17 12:05:37 UTC 2011


Hi all,

let's pick up this discussion again.

On 2011-07-25 19:03, Julien Cristau wrote:
> 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)

This is probably the way to go since there may be many "valid"
combinations thanks to multiarch.
Eventually a new "update-glx" utility could be introduced that allows
easy configuration of sane combinations:
  update-glx --set nvidia
which would update the libGL.so.1 alternatives for i386 and amd64 (if
available)

>> * one alternative (from an extra Multi-Arch: foreign package) that
>> covers all arches as slaves links?

That's the way currently done by glx-alternatives - but it only covers
amd64 and i386, a generic extension will be difficult.

>> * the Ubuntu approach of dropping something in ld.so.conf.d/ - would we
...
> Pretty please not messing with ld.so.conf.

OK, lets forget about this.


I'm about to send a patch for MESA which moves libGL.so* from $libdir to
$libdir/mesa/ and adds libGL.so and libGL.so.1 symlinks from $libdir to
the file in $libdir/mesa/.

This is a preparative step, the links in $libdir are to be replaced by
alternatives later on. For now, they will still be diverted by
glx-diversions. glx-alternative-mesa has already been updated to take
$libdir/mesa into account.

To effectively use diversions, the real files (libGL.so.1.*) need to be
moved out of $libdir, otherwise ldconfig may mess up the SONAME links.
With the current change it will already be possible to stop diverting
libGL.so.

I did not yet look into EGL, but I think it needs to be done similarily
there - move all libs that may get alternatives to $libdir/mesa/


Does XSF plan to backport MESA 7.11 to squeeze-backports? Is there a
planned timeframe? If my patch for the directory structure is accepted
and will go to squeeze-backports, too, it would significantly simplify
my plans for backporting nvidia-graphics-drivers.

Andreas



More information about the pkg-nvidia-devel mailing list