[oe] [OE-core] [RFC] OpenGL packaging/staging policy

[Burton, Ross]

Hi,

This was interesting discussion and certainly achieved the goal of
soliciting comments...  A less aggressive plan:

Rule 1.  Unambiguous package naming

I won't repeat this, everyone agreed this was sane.  I've a patch for
mesa that I'll submit shortly.

Rule 2.  No whitelisting for GL driver conflicts

The target GL shall be staged, and situations which result in multiple
GLs being installed should handle this case and resolve it.

For atom-pc this means building Mesa.  For Beagle this means staging
the Beagle binary drivers.  For Tegra as I've discovered this is
"interesting" as they don't appear to provide any headers in their
Tegra For Linux tarball...

For Cedar Trail and EMGD, the easiest solution is a dedicated Mesa
building just GL.  As Mesa's DRI driver API isn't stable this is
practically required anyway: the ABI of the libGL we build and the
libGL that the binary driver was built against need to match.  This
mesa-just-gl (mesa-solo?) can be in meta-intel unless other machines
turn out to have a similar (crazy) requirement.

Rule 3.  No dependencies on specific GL implementations

Useful so that GL implementations are swappable on systems where that
can happen, but not essential if there isn't a single blessed GL for
sysroot.  We'll do this later.

Some things that will also happen whilst I do this:
1) mesa-dri renamed to mesa.  Let's get this done nice and early!
2) mesa stops architecture-overriding enabling of EGL and GLES, so all
architectures that build Mesa get GL/EGL/GLESv1/GLESv2.  If you don't
want this don't build Mesa, and the namespaced packaging means there
won't be conflicts.

Any more comments?

Ross