[yocto] Support of meta-kde for Poky

[Samuel Stirtzel]

2012/3/26 Paul Eggleton <paul.eggleton at linux.intel.com>:
> On Monday 26 March 2012 14:55:40 Samuel Stirtzel wrote:
>> the development of meta-kde has come to a point where kde-applications
>> can be tested (and maybe used).
>>
>> Status of meta-kde:
>> Most common applications work, for example:
>> Calligra (not all of the toolkit), Kate, KCalc, Konqueror, Kwin &
>> Kwin_gles (KDE window manager), Okular and the applications from
>> KDE-baseapps.
>>
>> Plasma Active (and Desktop) do not work correctly, but I'm working on it.
>> Plasma Netbook seems to work, but it needs more testing.
>>
>>
>> Involving the community:
>> As the development of meta-kde advanced to a point where developers
>> can use the layer to port KDE applications.
>> I'd like to invite others to test the layer, port their favorite KDE
>> applications and express their opinions about the current status.
>> Feel free to ask questions and suggest applications to be ported.
>
> Great work! I will give it a try over the next few days and let you know how I
> get on. (Sorry I know I promised to do this some weeks ago.)
>
>> meta-kde has no mailing list, so I'm looking for a list to host the
>> discussion, any suggestions?
>
> Probably just the oe-devel list - if the volume of commits gets too high then
> we can look at splitting off a separate one.

Do I need an official statement, and from whom can I get it in case?

>
>> Current issues with Poky:
>> The giflib recipe is not contained in Poky.
>> Is this based on a design decision, or just because no one needs it?
>
> It's based upon nothing in OE-Core needing it. (The poky repository is just
> OE-Core + bitbake + meta-yocto + yocto-docs).
>
>> As a meta-kde developer I don't want to limit the testing of meta-kde.
>
> It should be OK to use meta-oe with Poky, and therefore meta-kde can depend
> upon it. However we are aware that meta-oe overlays a bunch of recipes that
> ideally it should not. We're working (albeit slowly) to address these.
>
> An alternative in the meantime would be to add giflib to meta-kde, this will do
> no significant harm if it is already available in another layer (and giflib
> doesn't look like it has really changed since 2008, so I don't think it will
> be much of a maintenance burden).

My assumption is that the initial request, that started this
discussion, was made with the idea in mind not to include any
"overhead" from meta-oe.
But TBH I don't know exactly.
Too bad it isn't possible to include only a subset of recipes from a layer..
But it just looks like layers don't work like that.

>
> As an aside it would be interesting to know why KDE requires additional gif
> support from giflib when gif loading is already built into Qt (and we do enable
> it in our Qt recipes).

The KDE gifloader code is from 2004.
It looks like this was a possible solution and it worked, so they kept it.
But since it is KHTML depending on giflib, KDE could replace it with
Webkit in the "future" (this is really old news).

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre



-- 
Regards
Samuel