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

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

On Wednesday 15 May 2013 10:19:57 Tomas Frydrych wrote:
> 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.

How does it prevent that? Surely if machine-specific changes are required then 
they will be required on top of a separate layer as much as they are if the 
recipes remain in OE-Core.

> > 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.

Yes, I agree, "sometimes"; the same could be said for almost any piece of 
software; new features and fixes come along and some of those will be too 
important to some users to ignore. The layer mechanism exists to allow specific 
recipes to be extended if needed. Having the recipes in OE-Core does not 
preclude their extension or replacement with newer versions elsewhere for 
those that need it.

> > 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.

You may well be right about the need to test on other GL implementations. That 
does not explain how moving them to a separate layer directly helps to address 
that need. You must also expect to make some changes to the recipes 
themselves, so what changes would you be making?
 
> > 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 ...

See above.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre