Re: Piglit in Poky

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Hi Koen,

On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote:
> Burton, Ross schreef op 23-12-13 19:01:
> > We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we
> > can run automated QA on the GL stack.  Piglit is currently residing in
> > meta-oe, but as Poky is a self-contained project we can't just add
> > meta-oe to it:  apart from the size of meta-oe, we can't ensure stability
> > if meta-oe makes incompatible changes that affect Poky.
> > 
> > Piglit isn't a stand-alone package, there are the dependencies of waffle,
> > python-mako and python-numpy to consider too.  There are two
> > possibilities I can see:
> > 
> > 1) Move piglit and deps to oe-core.  Piglit is for QA purposes only and
> > pushes the boundaries of "core platform".  In a sense this is a repeat of
> > the discussion we had with Midori...  does oe-core contain everything
> > needed to sufficiently exercise the core components it ships or not?
> > 
> > 2) Add piglit and deps to meta-yocto.  Probably a new layer called
> > meta-yocto-qa (or similar) because the Yocto Compatible guidelines forbid
> > mixing distribution policy and recipes.
> 
> Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's
> what it's actually is and would remove a lot of confusion when trying to
> explain that yocto is not a distro, even if the distro layer is called
> 'meta-yocto'.

This is a tangent, but a couple of points:

1) This rename would not come for free. We'd need to update people's existing 
bblayers.conf files on the fly, as we did when meta-yocto-bsp was split out of 
meta-yocto, and thus bump LCONF_VERSION; however, doing this only in poky has 
resulted in annoying problems when users remove poky from their configurations 
(since LCONF_VERSION is out-of-step between Poky and OE-Core, leading to 
confusing errors in this situation). Thus I think we'd want to solve this once 
and for all by bumping the value in OE-Core as well as Poky.

2) If you propose this rename, perhaps you will also consider renaming 
meta-oe, since that name within a similarly named meta-openembedded repository 
leads to a similar level of confusion...?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre