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

[Christopher James Halse Rogers]

On Fri, 2011-07-22 at 21:12 +0200, 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.
> 
> Please note I'm very busy right now, consequently far behind on anything
> X-related; sorry for that.
> 

In Ubuntu we use an alternatives system for switching between libGL
(and, soon, libEGL) implementations.  We indeed had endless troubles
with the diversions we used to have; the alternatives system seems to
have been significantly less trouble.

We ship the GL implementations in a private directory and use a
ld.so.conf snippet hung off the $DEB_HOST_MULTIARCH_GL_conf alternative
to add that directory to the library search path.

The proprietary drivers hang a bunch of other stuff off that
alternative, too: modprobe blacklists to prevent nouveau/radeon loading,
their annoyingly special libglx xorg modules, that sort of thing.  Based
on my informal impressions, I think this single-switch approach has
resulted in fewer bugs where users are using a broken mix of
proprietary/open pieces of the stack.  Bryce would probably have better
metrics on that.

If it's desired I'd be very happy to add the equivalent to the Debian
mesa packages, since it'd significantly reduce the Ubuntu changes we're
carrying.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20110725/7a2ec6db/attachment.pgp>