[OE-core] [RFC] Working toward a GNOME layer

[Koen Kooi]

Op 22 apr 2011, om 18:23 heeft Joshua Lock het volgende geschreven:

> On Thu, 2011-04-21 at 20:12 +0200, Koen Kooi wrote:
>> Op 21 apr 2011, om 19:41 heeft Joshua Lock het volgende geschreven:
>> 
>>> On Thu, 2011-04-21 at 19:29 +0200, Koen Kooi wrote:
>>>> Op 21 apr 2011, om 18:40 heeft Joshua Lock het volgende geschreven:
>>>> 
>>>>> On Thu, 2011-04-21 at 16:05 +0100, Paul Eggleton wrote:
>>>>>> On Thursday 21 April 2011 15:02:49 Koen Kooi wrote:
>>>>>>> and possibly more. I would like to create a meta-gnome layer in the
>>>>>>> meta-openembedded repository where new recipes get added and things from
>>>>>>> meta-demoapps can get moved over into. Long term recipes-gnome in oe-core
>>>>>>> should move there as well.
>>>>>>> 
>>>>>>> What are your thoughts on this?
>>>>> 
>>>>> +1
>>>>> 
>>>>>> 
>>>>>> From my perspective this sounds like a great idea. The only question would be 
>>>>>> how much of the "GNOME" libs would remain in oe-core as some of them are quite 
>>>>>> widely used outside of GNOME proper; however that can easily be worked out as 
>>>>>> these things mature.
>>>>> 
>>>>> +1
>>>>> 
>>>>> My personal opinion would be that we start with glib & gtk+ (plus their
>>>>> dependencies, i.e. pango, atk, etc) in core and move the rest out to a
>>>>> layer.
>>>>> 
>>>>> I feel that Gtk+ is used by enough non-gnome software that it belongs in
>>>>> core but others may disagree?
>>>>> 
>>>>> Between meta/recipes-gnome and meta-demoapps we have a reasonable start
>>>>> to a meta-gnome/
>>>> 
>>>> Where did meta-demoapps go? It's not in OE-core anymore by the looks of it.
>>> 
>>> Hmm, still exists for me:
>>> 
>>> joshual at vorpal:~/Projects/Yocto/oe-core/meta-demoapps[master]
>>> $ pwd
>>> /home/joshual/Projects/Yocto/oe-core/meta-demoapps
>>> 
>>> 
>>>> 
>>>>> I'd be happy to help with this layer.
>>>> 
>>>> Awesome, do you have any objection to put meta-gnome into the meta-openembedded repo for the time being? Once we get better tooling we can move it elsewhere, of course.
>>> 
>>> None whatsoever. I keep meaning to push some recipes into that layer
>>> anyway.
>> 
>> I just sent out 10 patches for review that import recipes-gnome from meta-demoapps into meta-gnome. Please review :)
> 
> The way I see it there are two approaches, tidy & test the recipes then
> merge *or* merge then fix.
> 
> If we're going for the latter approach let's get your patches merged!

While I'd love the first approach, the second is a lot more practical for 'yocto' recipes, I would reserve the vetting for the ones imported from OE. Does that sound OK?

> This does raise another question, is meta-oe striving for the same
> standards of metadata as oe-core? i.e. SRC_URI & license checksums,
> updated patch syntax, etc.

It does, but it still has crud in it from "the early days" which needs to get cleaned up. No license checksum is fatal, so that one is covered, but the source checksums aren't.  I would be nice to make the following errors fatal (if they haven't already):

1) license checksums
2) LDFLAGS (gnu-hash)
3) source checksums

> Also, how much gnome do we want to support? Are we trying to be all new
> and shiny and drop deprecated libraries (gnome-vfs)?

Personally I would go for importing 2.30 from OE and see if there are 2.32 updates available. 2.30 should be relatively gnome-vfs free. So for this specific example, let's try to avoid gnome-vfs. In a broader sense, let's get gnome 2 in and look at gnome 3 later. I suspect gnome 3 will be a world of hurt with its clutter and hence openGL requirements.

> Just trying to work out what patches to work on ;-)

Which reminds me, the gtk+ in meta-oe needs to get compared to the one in oe-core to see what's different, I don't want to keep a copy in meta-oe.

> Perhaps we can
> define a policy of what's appropriate for the layer in a README?

Are you volunteering to draft a README? If so, go for it :)

regards,

Koen