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 Richard,

On 10/05/13 10:05, Richard Purdie wrote:
>> Yes, I could have submitted clutter 1.12 recipes to oe-core in some form
>> and shape in the last 6 months, and we would have had a less outdated
>> package in oe-core; but nevertheless outdated, since again the clutter
>> 1.14 release came too late to make it into dylan. I can see this
>> happening again and again.
> 
> The trouble is you can make this argument for every single piece of
> software in OE-Core.

The clutter related packages are the only ones where I have run into
this problem. In the last 12 months clutter went through 7 stable
releases or so, of these there were 3 minor version changes, which
signal API changes, another minor version change, as well as a major
version change to 2.0, is on the horizon. If you are developing an
application using clutter; you need to keep up. If you are using
Yocto/OE to develop an application using clutter (and people do), then
everyone is left to maintain their own rolling recipes.


> A dedicated layer will still have timing issues, it will just move onto
> your personal schedule rather than the OE-Core one and whilst this will
> obviously suit you, it likely won't suit all other users.

For a small dedicated layer the schedule can closely track the upstream.
It might not suit all clutter users, but I think it could be made to
work for most of them; the current situation suits no one at all.


> I suspect the bigger problem here is that clutter is hard to write
> recipes for since it needs to suit a number of different targets and
> configurations. Going to the effort of doing a generic implementation in
> OE-Core is hard, whereas creating your own layer means you can customise
> to your usecase and not worry about the other cases. I suspect your
> reply to this will be that anyone wanting to add other cases can send
> you patches. The implication is that the layer will become much more
> specialised/focused than the core recipes currently are.

My reply is that it clutter is not that complex, there are only a finite
number of possible configurations that make sense and it should be
entirely possible to write a good base recipe that can be easily tweaked
using a bbappend based on machine and distro needs. But that's not the
real issue.


> My preference would still be to fix up the recipes in the core, than
> have some specific branches for danny/dylan with the 1.12/1.14
> components in if/as needed. We can create the core recipes so they're
> properly configurable to the different usecases.

Fixing up the recipes in oe-core only addresses one aspect of the
problem. The fast turnover of the clutter packages will remain, as will
the fact that nothing in oe-core uses clutter, so the oe-core packages
are untested. Then there is the fact that oe-core does not have any
machines that clutter could be really used with. Then there are also
other projects that are closely tied to clutter version, such as (the
recently removed) mutter, and, dare I say, GnomeShell, which should be
maintained together.

I am still to hear any reason why clutter should be in oe-core ... the
same logic that said mutter should be removed from oe-core applies to
clutter, I think.

Tomas