Re: proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer

[Tomas Frydrych <tf+lists.yocto@r-finger.com>]

Hi Paul,

On 14/05/13 17:55, Paul Eggleton wrote:
> Having clutter in OE-Core does not preclude such testing with additional BSPs, 
> and I'm unclear on how moving it out to another layer helps at all with this 
> specific issue.

It prevents efficiently supporting clutter on any real machine that does
not use mesa's GL, which means all machines not in meta-intel, and some
machines in meta-intel. This is the main issue, real HW support.


> This could present a problem. What if I want Clutter but I don't want the 
> latest version of glib, but instead the version that is being shipped with OE-
> Core that is tested with the other pieces of the system that depend upon it 
> (especially given glib has recent history of breaking other packages)? Surely 
> the safest alternative is the last stable version of Clutter that works with 
> that version of glib? That would make it difficult to depend upon an external 
> layer that provides its own newer version of glib would it not?

Sometimes a 6 month old release is not enough, and having to provide the
updated packages yourself is the least desirable of all options. In a
small layer, such issues can be handled gracefully, and their impact
limited.


> There's no denying that the maintenance of the Clutter recipes in OE-Core has 
> slipped. I don't think that is an argument in itself to split them out, that 
> just means we need to recognise that and maintain those recipes more 
> effectively.

The lack of maintenance reflects the relative importance of Clutter for
oe-core, and is an orthogonal issue. I am not complaining that it is not
being maintained, I am arguing that it cannot be properly maintained
with just reference to mesa and qemu, hence the suggestion to split it out.


> Honestly I think if Clutter continues to be something that people are using to 
> develop applications we're much better off with the "canonical" stable version 
> being in OE-Core.

Where 'canonical' means 'unusable on non-Intel HW', but I am repeating
myself ...

Tomas