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

[Mark Hatle]

On 10/22/12 11:35 AM, Burton, Ross wrote:
> Hi,
>
> Now that we've almost got 1.3 out of the door we can go back to
> breaking everything. Hooray!  Let's try to (un)break OpenGL again.
>
> First, I should say that I'm not looking at this from an GenX/Intel
> specific perspective where Mesa is all you need.  meta-intel ships two
> different binary GL drivers (cdt-pvr for Cedar Trail, EMGD for
> everything else Atom that doesn't have i945) so I'm perfectly aware of
> the problems.
>
> For example, Cedar Trail's (SGX545-based) GL stack comprises of GLESv1
> GLESv2 and EGL library blobs, and a DRI driver blob.  This DRI driver
> can be used by Mesa's libGL.  This is actually a more complex problem
> than Beagle has where it just doesn't do GL.
>
> This is my attempt at a simple solution that doesn't involve
> complicated packaging tricks.
>
> Rule 1.  Unambiguous package naming
>
> Debian-style renaming and multiple providers of the same API doesn't
> work as you'll end up with multiple packages in the same feed called
> libgl1, so all GL packages should be named in the style of libgl-foo,
> where foo is the source of the package.  I've got a branch where this
> is implemented for Mesa as a proof of concept[1], and the Python
> fragment could easily be moved into a class and re-used easily.

I can't say I'm a fan of the debian renamining, but in this case I think it's 
very important to do this.  Using the pkgv_<name> = 'libgl-foo' is a good idea.. 
  I'm guessing that is the easiest way to get consistent behavior.

> Rule 2. No dependencies on specific GL implementations
>
> Packages currently depend on the exact GL that they were built with,
> although the GL packages are swappable.  Not very interesting for
> systems where there's only one provider, but still a valid problem for
> systems with swappable hardware or alternative GL stacks.  All linkage
> to the GL stack should be intercepted and replaced by something like
> "virtual/libgl | libgl-mesa".

Moving everything to libgl1, or virtual/libgl or similar is what I would 
suggest.  This is consistent with the rest of the system behavior.

> This means changing the shlib dependency detection code to support
> per-library overrides, there's plenty of prior art in existing
> distributions to help here.

Each of the libgl's should have equivalent provides (i.e. libgl1)

> Rule 3. Only Mesa stages, nothing else
>
> Whilst there are multiple GL implementations that offer various
> subsets of GL, they are all effectively interchangeable.  It's not a
> massive concern what exact GL is present when building because they've
> all got the same API.  We can take advantage of this and remove the
> problems caused by multiple GL implementations staging by only putting
> Mesa into the sysroot.  Any other GL implementation should explicitly
> stop staging itself to avoid sysroot tainting.  This can be
> implemented by making Mesa build all APIs on all platforms (which
> isn't a problem when it comes to image building or feeds, thanks to
> rule 1), and removing the virtual/libgl PROVIDES from the other GL
> implementations.
>
> For systems which don't use Mesa at all (for example, BeagleBoard)
> then this potentially means that Mesa will be built when it shouldn't.
>   GLX support in the X server may already be pulling it in (I made this
> a packageconfig in 1.3 so distros can turn it off), but in any case I
> think this is an acceptable compromise - Mesa isn't slow to build in
> the scheme of things, and per Rule 2 this is purely in sysroot and not
> in the images.

For systems like BeagleBoard, do they use X11, if so what do they use for GL? 
Most of the ARM systems use raw direct PowerVR drivers in my experience, and 
generally don't use X11.

We definitely need a solution for X11 / Mesa based systems.. and a way to 
qualify the other systems with the way their graphics solutions are built.

--Mark

>
> tl;dr: all packages built against a constant GL, all GL
> implementations interchangable, no package conflicts in the feeds.
>
> Any comments before I get my hands dirty with the next incomplete task
> (shlib dependency generation)?
>
> Ross
>
> [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mesa&id=784fa1372bb38dbc82e53a49b757c3c02593f2b8
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>