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

Tomas Frydrych tf+lists.yocto at r-finger.com
Mon Oct 29 18:27:44 UTC 2012


On 29/10/12 17:26, Burton, Ross wrote:
> 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?

FWIW, I am happy with this proposal :)

Tomas





More information about the Openembedded-core mailing list