Qt in OE-core

Qt in OE-core

[Trevor Woerner]

Hello everyone,

question:
Should some version of Qt be included in openembedded-core, or should
all recipes to add Qt be part of their own version-specific Qt layer?


background:
openembedded-core[1] used to include recipes for Qt3, but as Qt3 became
old these recipes were replaced with Qt4 and the Qt3 support was broken
out into its own layer[2]. We're now at a point where Qt4 is getting old
and Qt5 is "current". At some point we'll have to replace the Qt4
support in [1] with support for Qt5. But we expect users will still want
to use Qt4, so if the Qt4 support in [1] is replaced by support for Qt5,
the Qt4 support will need to be broken out into its own layer. Qt5
support is currently being developed on it's own layer[3].


This email thread is *not* to discuss when we should replace Qt4 with
Qt5, then question is: should [1] include *any* Qt support, or should Qt
be always in its own layer to be added as required by the distribution?


If we decide [1] should provide some Qt support, then we can discuss
when we should replace the Qt4 support with Qt5 in [1]. But for now it
would be nice to reach a consensus on whether or not [1] should include
any Qt support at all or if it wouldn't just be easier to always have Qt
support in its own version-specific layers to be added as required (if
needed) by the distribution configuration.


Thanks for your feedback.



[1]
http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/
[2] http://layers.openembedded.org/layerindex/branch/master/layer/meta-qt3/
[3] http://layers.openembedded.org/layerindex/branch/master/layer/meta-qt5/

Re: Qt in OE-core

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

On Tue, Jan 07, 2014 at 01:27:22PM -0500, Trevor Woerner wrote:
> Hello everyone,
> 
> question:
> Should some version of Qt be included in openembedded-core, or should
> all recipes to add Qt be part of their own version-specific Qt layer?
> 
> 
> background:
> openembedded-core[1] used to include recipes for Qt3, but as Qt3 became
> old these recipes were replaced with Qt4 and the Qt3 support was broken
> out into its own layer[2]. We're now at a point where Qt4 is getting old
> and Qt5 is "current". At some point we'll have to replace the Qt4
> support in [1] with support for Qt5. But we expect users will still want
> to use Qt4, so if the Qt4 support in [1] is replaced by support for Qt5,
> the Qt4 support will need to be broken out into its own layer. Qt5
> support is currently being developed on it's own layer[3].
> 
> 
> This email thread is *not* to discuss when we should replace Qt4 with
> Qt5, then question is: should [1] include *any* Qt support, or should Qt
> be always in its own layer to be added as required by the distribution?
> 
> 
> If we decide [1] should provide some Qt support, then we can discuss
> when we should replace the Qt4 support with Qt5 in [1]. But for now it
> would be nice to reach a consensus on whether or not [1] should include
> any Qt support at all or if it wouldn't just be easier to always have Qt
> support in its own version-specific layers to be added as required (if
> needed) by the distribution configuration.

I would like to see qt4 moved from oe-core to meta-qt4.

That would remove the feeling that using oe-core defaults to using qt4
and it would be consistent with other QT layers:

meta-qt3
meta-qt4
meta-qt5

oe-core would stay just the "core" and if you need any QT you can select
which one suits your needs the most (or combination of e.g. qt4+qt5 like
most people are using now)

With PACKAGECONFIGs which can list optional dependencies which aren't
included in the the layer itself it's now easier to have recipe with
optional qt5 support in oe-core, but qt5 itself in separate meta-qt5.

Another interesting aspect is that with qt4 we have only 6 recipes in
openembedded-core/meta/recipes-qt/qt4

while
meta-qt5/recipes-qt/qt5 has 25 different recipes (many of them with
_git.bb variant so 42 in total). And splitting the qt5 recipes (e.g. to
have only qtbase, qtdeclarative in oe-core and "additional" modules in
separate meta-qt5) isn't very good, because they are quite tightly
coupled (so upgrading recipes in meta-qt5 would be in many cases
incomatible with qtbase version in oe-core and vice-versa).

Another advantage of separate meta-qt5 layer is that in many projects
people are using older oe-core release (e.g. dylan) with newer meta-qt5
(e.g. dora or master or even qt5-5.2.0 branch), with separate layer it's
easier to mix them.

Just my 2BTC as meta-qt5 maintainer.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Qt in OE-core

[Richard Purdie]

On Tue, 2014-01-07 at 20:23 +0100, Martin Jansa wrote:
> I would like to see qt4 moved from oe-core to meta-qt4.
>
> That would remove the feeling that using oe-core defaults to using qt4
> and it would be consistent with other QT layers:
> 
> meta-qt3
> meta-qt4
> meta-qt5
> 
> oe-core would stay just the "core" and if you need any QT you can select
> which one suits your needs the most (or combination of e.g. qt4+qt5 like
> most people are using now)
> 
> With PACKAGECONFIGs which can list optional dependencies which aren't
> included in the the layer itself it's now easier to have recipe with
> optional qt5 support in oe-core, but qt5 itself in separate meta-qt5.
> 
> Another interesting aspect is that with qt4 we have only 6 recipes in
> openembedded-core/meta/recipes-qt/qt4
> 
> while
> meta-qt5/recipes-qt/qt5 has 25 different recipes (many of them with
> _git.bb variant so 42 in total). And splitting the qt5 recipes (e.g. to
> have only qtbase, qtdeclarative in oe-core and "additional" modules in
> separate meta-qt5) isn't very good, because they are quite tightly
> coupled (so upgrading recipes in meta-qt5 would be in many cases
> incomatible with qtbase version in oe-core and vice-versa).

What dependencies on other layers does meta-qt5 have?

If the policy is all qt5 things into meta-qt5, the risk is a fairly
large set of layer dependencies for meta-qt5.

There is some perception I don't like external layers which isn't true. 

What I do dislike is "dependency creep". If the meta-qt5 isn't usable
without pulling in chunks of meta-oe for example, I'd think that rather
sad and it might as well move to meta-oe at that point.

Also, whilst there are only 6 qt4 recipes in core, they are (at least as
far as I know) the core qt components that people base off so in that
sense we're enabling developers and don't have a ton of "apps" around
they probably wouldn't want to use.

Cheers

Richard

Re: Qt in OE-core

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]

Hello folks,

On Tue, Jan 7, 2014 at 5:23 PM, Martin Jansa <martin.jansa@gmail.com> wrote:

> On Tue, Jan 07, 2014 at 01:27:22PM -0500, Trevor Woerner wrote:
> > Hello everyone,
> >
> > question:
> > Should some version of Qt be included in openembedded-core, or should
> > all recipes to add Qt be part of their own version-specific Qt layer?
> >
> >
> > background:
> > openembedded-core[1] used to include recipes for Qt3, but as Qt3 became
> > old these recipes were replaced with Qt4 and the Qt3 support was broken
> > out into its own layer[2]. We're now at a point where Qt4 is getting old
> > and Qt5 is "current". At some point we'll have to replace the Qt4
> > support in [1] with support for Qt5. But we expect users will still want
> > to use Qt4, so if the Qt4 support in [1] is replaced by support for Qt5,
> > the Qt4 support will need to be broken out into its own layer. Qt5
> > support is currently being developed on it's own layer[3].
> >
> >
> > This email thread is *not* to discuss when we should replace Qt4 with
> > Qt5, then question is: should [1] include *any* Qt support, or should Qt
> > be always in its own layer to be added as required by the distribution?
> >
> >
> > If we decide [1] should provide some Qt support, then we can discuss
> > when we should replace the Qt4 support with Qt5 in [1]. But for now it
> > would be nice to reach a consensus on whether or not [1] should include
> > any Qt support at all or if it wouldn't just be easier to always have Qt
> > support in its own version-specific layers to be added as required (if
> > needed) by the distribution configuration.
>
> I would like to see qt4 moved from oe-core to meta-qt4.
>
> That would remove the feeling that using oe-core defaults to using qt4
> and it would be consistent with other QT layers:
>
> meta-qt3
> meta-qt4
> meta-qt5
>

Agreed.


> oe-core would stay just the "core" and if you need any QT you can select
> which one suits your needs the most (or combination of e.g. qt4+qt5 like
> most people are using now)
>
> With PACKAGECONFIGs which can list optional dependencies which aren't
> included in the the layer itself it's now easier to have recipe with
> optional qt5 support in oe-core, but qt5 itself in separate meta-qt5.
>
> Another interesting aspect is that with qt4 we have only 6 recipes in
> openembedded-core/meta/recipes-qt/qt4
>
> while
> meta-qt5/recipes-qt/qt5 has 25 different recipes (many of them with
> _git.bb variant so 42 in total). And splitting the qt5 recipes (e.g. to
> have only qtbase, qtdeclarative in oe-core and "additional" modules in
> separate meta-qt5) isn't very good, because they are quite tightly
> coupled (so upgrading recipes in meta-qt5 would be in many cases
> incomatible with qtbase version in oe-core and vice-versa).
>
> Another advantage of separate meta-qt5 layer is that in many projects
> people are using older oe-core release (e.g. dylan) with newer meta-qt5
> (e.g. dora or master or even qt5-5.2.0 branch), with separate layer it's
> easier to mix them.
>

Fully agreed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 4260 bytes --]

Re: Qt in OE-core

[Paul Eggleton]

Hi all,

On Tuesday 07 January 2014 13:27:22 Trevor Woerner wrote:
> question:
> Should some version of Qt be included in openembedded-core, or should
> all recipes to add Qt be part of their own version-specific Qt layer?
> 
> background:
> openembedded-core[1] used to include recipes for Qt3, but as Qt3 became
> old these recipes were replaced with Qt4 and the Qt3 support was broken
> out into its own layer[2]. We're now at a point where Qt4 is getting old
> and Qt5 is "current". At some point we'll have to replace the Qt4
> support in [1] with support for Qt5. But we expect users will still want
> to use Qt4, so if the Qt4 support in [1] is replaced by support for Qt5,
> the Qt4 support will need to be broken out into its own layer. Qt5
> support is currently being developed on it's own layer[3].
> 
> This email thread is *not* to discuss when we should replace Qt4 with
> Qt5, then question is: should [1] include *any* Qt support, or should Qt
> be always in its own layer to be added as required by the distribution?
> 
> If we decide [1] should provide some Qt support, then we can discuss
> when we should replace the Qt4 support with Qt5 in [1]. But for now it
> would be nice to reach a consensus on whether or not [1] should include
> any Qt support at all or if it wouldn't just be easier to always have Qt
> support in its own version-specific layers to be added as required (if
> needed) by the distribution configuration.

I can see some benefits to having Qt in a separate layer, and this is not the 
first time this question has come up. However, one concern I have always had 
with Qt being moved out of OE-Core though is that I very much doubt the same 
will happen with GTK+ and GNOME UI components that we carry, which I think 
will lead to the (perhaps erroneous, but logical) assumption in new users' 
minds that we support or recommend these more than we do Qt. Given Qt's 
popularity in the embedded space I don't think this would be the right message 
to be sending out.

Any concrete ideas on how we would address this perception issue?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Qt in OE-core

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

On Wed, Jan 08, 2014 at 03:56:04PM +0000, Paul Eggleton wrote:
> Hi all,
> 
> On Tuesday 07 January 2014 13:27:22 Trevor Woerner wrote:
> > question:
> > Should some version of Qt be included in openembedded-core, or should
> > all recipes to add Qt be part of their own version-specific Qt layer?
> > 
> > background:
> > openembedded-core[1] used to include recipes for Qt3, but as Qt3 became
> > old these recipes were replaced with Qt4 and the Qt3 support was broken
> > out into its own layer[2]. We're now at a point where Qt4 is getting old
> > and Qt5 is "current". At some point we'll have to replace the Qt4
> > support in [1] with support for Qt5. But we expect users will still want
> > to use Qt4, so if the Qt4 support in [1] is replaced by support for Qt5,
> > the Qt4 support will need to be broken out into its own layer. Qt5
> > support is currently being developed on it's own layer[3].
> > 
> > This email thread is *not* to discuss when we should replace Qt4 with
> > Qt5, then question is: should [1] include *any* Qt support, or should Qt
> > be always in its own layer to be added as required by the distribution?
> > 
> > If we decide [1] should provide some Qt support, then we can discuss
> > when we should replace the Qt4 support with Qt5 in [1]. But for now it
> > would be nice to reach a consensus on whether or not [1] should include
> > any Qt support at all or if it wouldn't just be easier to always have Qt
> > support in its own version-specific layers to be added as required (if
> > needed) by the distribution configuration.
> 
> I can see some benefits to having Qt in a separate layer, and this is not the 
> first time this question has come up. However, one concern I have always had 
> with Qt being moved out of OE-Core though is that I very much doubt the same 
> will happen with GTK+ and GNOME UI components that we carry, which I think 
> will lead to the (perhaps erroneous, but logical) assumption in new users' 
> minds that we support or recommend these more than we do Qt. Given Qt's 
> popularity in the embedded space I don't think this would be the right message 
> to be sending out.
> 
> Any concrete ideas on how we would address this perception issue?

Link to layerindex in meta/recipes-qt/qt5 directory? :)

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Qt in OE-core

[Trevor Woerner]

On 01/08/14 10:56, Paul Eggleton wrote:
> However, one concern I have always had with Qt being moved out of
> OE-Core though is that I very much doubt the same will happen with
> GTK+ and GNOME UI components that we carry, which I think will lead to
> the (perhaps erroneous, but logical) assumption in new users' minds
> that we support or recommend these more than we do Qt. Given Qt's
> popularity in the embedded space I don't think this would be the right
> message to be sending out. Any concrete ideas on how we would address
> this perception issue? 

Would it be worthwhile to ask that the OE TSC take on the task of
defining what is "core" and what is not? Does this definition already exist?

From the moment OE chose to adopt a layered strategy, people started
questioning how to define a layer and what recipes should be part of one
layer versus another. But it doesn't seem as though there's been much
interest in setting any definite rules or definitions in this regard.
Maybe it would be worth the effort to at least try?

In my opinion...

Personally I would be in favour of removing GTK+ and the GNOME UI from
the core and putting them in their own layer for all the same reasons I
think Qt should be in its own layer:
- a "basic" image doesn't need them
- we can have different layers to track separate major releases (as with
qt3, qt4, and qt5)

There are so many ways to do GUI "things" on top of a Linux system.
Frankly I'm not even in a position where I could enumerate all of them,
or even sort them out:
- x11, wayland, mir, (directfb)
(http://en.wikipedia.org/wiki/Display_server)
- qt, gtk+, wxwidgets, tcl/tk, fltk
(http://en.wikipedia.org/wiki/List_of_widget_toolkits)
- xlib, xcb (client libraries implementing x11 protocol)
- weston, mutter, kwin, clayland (display servers implementing the
wayland display server protocol)
- opengl, opengles, egl, ...

(I can't even begin to figure out how to draw a diagram that shows how
all these projects fit together!)

Maybe if there are significant competing projects which do the same
thing, then they should be implemented in their own layer:
- meta-python
- meta-perl

And if there are completing projects which do the same thing but which
aren't significantly large projects on their own (e.g.
http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers) then
they should form a layer together of their own:
- meta-apache-httpd
- meta-http-servers
  - boa
  - cherokee
  - lighttpd
  - nginx

Or maybe all projects which do the same thing different ways should be
in their own layer? That way we don't have to distinguish between
"significant" and "lightweight" projects"
- meta-scripting-languages
  - python
  - perl
  - ruby
- meta-http-servers
  - apache
  - boa
  - cherokee
  - lighttpd
  - nginx

And maybe "core" should be just enough to get a console-based image working?

Re: Qt in OE-core

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

On Wed, Jan 08, 2014 at 01:44:59PM -0500, Trevor Woerner wrote:
> On 01/08/14 10:56, Paul Eggleton wrote:
> > However, one concern I have always had with Qt being moved out of
> > OE-Core though is that I very much doubt the same will happen with
> > GTK+ and GNOME UI components that we carry, which I think will lead to
> > the (perhaps erroneous, but logical) assumption in new users' minds
> > that we support or recommend these more than we do Qt. Given Qt's
> > popularity in the embedded space I don't think this would be the right
> > message to be sending out. Any concrete ideas on how we would address
> > this perception issue? 
> 
> Would it be worthwhile to ask that the OE TSC take on the task of
> defining what is "core" and what is not? Does this definition already exist?
> 
> From the moment OE chose to adopt a layered strategy, people started
> questioning how to define a layer and what recipes should be part of one
> layer versus another. But it doesn't seem as though there's been much
> interest in setting any definite rules or definitions in this regard.
> Maybe it would be worth the effort to at least try?
> 
> In my opinion...
> 
> Personally I would be in favour of removing GTK+ and the GNOME UI from
> the core and putting them in their own layer for all the same reasons I
> think Qt should be in its own layer:

The same for meta-x11 or meta-xorg, even when a lot of projects (maybe
the most) will just include meta-x* by default.

> - a "basic" image doesn't need them
> - we can have different layers to track separate major releases (as with
> qt3, qt4, and qt5)
> 
> There are so many ways to do GUI "things" on top of a Linux system.
> Frankly I'm not even in a position where I could enumerate all of them,
> or even sort them out:
> - x11, wayland, mir, (directfb)
> (http://en.wikipedia.org/wiki/Display_server)
> - qt, gtk+, wxwidgets, tcl/tk, fltk
> (http://en.wikipedia.org/wiki/List_of_widget_toolkits)
> - xlib, xcb (client libraries implementing x11 protocol)
> - weston, mutter, kwin, clayland (display servers implementing the
> wayland display server protocol)
> - opengl, opengles, egl, ...
> 
> (I can't even begin to figure out how to draw a diagram that shows how
> all these projects fit together!)
> 
> Maybe if there are significant competing projects which do the same
> thing, then they should be implemented in their own layer:
> - meta-python
> - meta-perl
> 
> And if there are completing projects which do the same thing but which
> aren't significantly large projects on their own (e.g.
> http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers) then
> they should form a layer together of their own:
> - meta-apache-httpd
> - meta-http-servers
>   - boa
>   - cherokee
>   - lighttpd
>   - nginx
> 
> Or maybe all projects which do the same thing different ways should be
> in their own layer? That way we don't have to distinguish between
> "significant" and "lightweight" projects"
> - meta-scripting-languages
>   - python
>   - perl
>   - ruby
> - meta-http-servers
>   - apache
>   - boa
>   - cherokee
>   - lighttpd
>   - nginx
> 
> And maybe "core" should be just enough to get a console-based image working?

+1 for whole e-mail.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Qt in OE-core

[Paul Eggleton]

On Wednesday 08 January 2014 13:44:59 Trevor Woerner wrote:
> On 01/08/14 10:56, Paul Eggleton wrote:
> > However, one concern I have always had with Qt being moved out of
> > OE-Core though is that I very much doubt the same will happen with
> > GTK+ and GNOME UI components that we carry, which I think will lead to
> > the (perhaps erroneous, but logical) assumption in new users' minds
> > that we support or recommend these more than we do Qt. Given Qt's
> > popularity in the embedded space I don't think this would be the right
> > message to be sending out. Any concrete ideas on how we would address
> > this perception issue?
> 
> Would it be worthwhile to ask that the OE TSC take on the task of
> defining what is "core" and what is not? Does this definition already exist?

If we can't come up with a consensus here, then yes. The trouble is one 
person's idea of "core" is likely going to be very different to another's. If 
your UI is written using Qt, that's going to be core to what you are doing. If 
your UI is a custom one written using SDL you won't give two hoots about 
recipes for building Qt/GTK+ and everything related. Where do you draw the 
line?

Although it hasn't been rigorously defined since the beginning and there are 
definitely some fuzzy edges, I think the selection of recipes in OE-Core has 
worked reasonably well. We should stop from time to time to evaluate it, but 
equally we should think carefully before we pull the whole thing to pieces.
 
> From the moment OE chose to adopt a layered strategy, people started
> questioning how to define a layer and what recipes should be part of one
> layer versus another. But it doesn't seem as though there's been much
> interest in setting any definite rules or definitions in this regard.
> Maybe it would be worth the effort to at least try?

We should certainly have the discussion, yes.

> In my opinion...
> 
> Personally I would be in favour of removing GTK+ and the GNOME UI from
> the core and putting them in their own layer for all the same reasons I
> think Qt should be in its own layer:
> - a "basic" image doesn't need them
> - we can have different layers to track separate major releases (as with
> qt3, qt4, and qt5)

The trouble is, if you have no toolkit at all, how do you test that X still 
works properly? The selection we have provides a single unit allowing us to 
test the entire stack reasonably well without having to add anything else. I 
think that's a valuable thing to have.

> There are so many ways to do GUI "things" on top of a Linux system.
> Frankly I'm not even in a position where I could enumerate all of them,
> or even sort them out:
> - x11, wayland, mir, (directfb)
> (http://en.wikipedia.org/wiki/Display_server)
> - qt, gtk+, wxwidgets, tcl/tk, fltk
> (http://en.wikipedia.org/wiki/List_of_widget_toolkits)
> - xlib, xcb (client libraries implementing x11 protocol)
> - weston, mutter, kwin, clayland (display servers implementing the
> wayland display server protocol)
> - opengl, opengles, egl, ...

Don't forget EFL, SDL (and now SDL2), cogl, framebuffer (w/o DirectFB) although 
apart from EFL these don't really bring much in the way of large numbers of 
associated recipes. To be fair, within OE-Core we have picked a fairly small 
selection of toolkits/frameworks that are commonly used and that make use of a 
broad range of system functionality.

> Maybe if there are significant competing projects which do the same
> thing, then they should be implemented in their own layer:
> - meta-python
> - meta-perl

We have meta-perl in the meta-openembedded repository (with not much in it, 
but there are numbers of recipes "in the pipeline"). I'm also in favour of 
creating a meta-python there as well. In both cases though I wouldn't expect 
to move anything that's currently in OE-Core to there, because generally that 
stuff is in OE-Core to support other items in OE-Core (unless the latter 
changes, of course.)

> And if there are completing projects which do the same thing but which
> aren't significantly large projects on their own (e.g.
> http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers) then
> they should form a layer together of their own:
> - meta-apache-httpd
> - meta-http-servers
>   - boa
>   - cherokee
>   - lighttpd
>   - nginx
>
> Or maybe all projects which do the same thing different ways should be
> in their own layer? That way we don't have to distinguish between
> "significant" and "lightweight" projects"
> - meta-scripting-languages
>   - python
>   - perl
>   - ruby
> - meta-http-servers
>   - apache
>   - boa
>   - cherokee
>   - lighttpd
>   - nginx
> 
> And maybe "core" should be just enough to get a console-based image working?

We already have meta-webserver in the meta-openembedded repository - that's 
currently covering all of the web servers except boa and lighttpd (there is no 
recipe for boa, and lighttpd is in OE-Core, but I'm not entirely sure why) 
plus PHP recipes (though not standalone PHP, should probably fix that), and 
standalone web admin UIs. We had a similar discussion around the time meta-
webserver was created; there was speculation (on my part IIRC) that we might 
have a significant growth e.g. in the number of PHP recipes that would warrant 
a specific PHP layer; in the end we decided not to create that layer 
preemptively however, and it's probably a good thing since that growth hasn't 
happened.

To me, the major criteria for creating additional layers is pretty much this:

1) Can you collect a significant number of related recipes together for the 
layer that doesn't really fit well into an existing layer? Splitting out one or 
two existing recipes to a separate layer just adds overhead (both for 
maintainers and for users) without much in the way of benefit.

2) Is there someone (or a small group of people) who will step up and agree to 
maintain the layer?

3) What does it mean in terms of the dependencies between layers?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Qt in OE-core

[Richard Purdie]

On Wed, 2014-01-08 at 23:21 +0000, Paul Eggleton wrote:
> On Wednesday 08 January 2014 13:44:59 Trevor Woerner wrote:
> > On 01/08/14 10:56, Paul Eggleton wrote:
> > > However, one concern I have always had with Qt being moved out of
> > > OE-Core though is that I very much doubt the same will happen with
> > > GTK+ and GNOME UI components that we carry, which I think will lead to
> > > the (perhaps erroneous, but logical) assumption in new users' minds
> > > that we support or recommend these more than we do Qt. Given Qt's
> > > popularity in the embedded space I don't think this would be the right
> > > message to be sending out. Any concrete ideas on how we would address
> > > this perception issue?
> > 
> > Would it be worthwhile to ask that the OE TSC take on the task of
> > defining what is "core" and what is not? Does this definition already exist?
> 
> If we can't come up with a consensus here, then yes. The trouble is one 
> person's idea of "core" is likely going to be very different to another's. If 
> your UI is written using Qt, that's going to be core to what you are doing. If 
> your UI is a custom one written using SDL you won't give two hoots about 
> recipes for building Qt/GTK+ and everything related. Where do you draw the 
> line?
> 
> Although it hasn't been rigorously defined since the beginning and there are 
> definitely some fuzzy edges, I think the selection of recipes in OE-Core has 
> worked reasonably well. We should stop from time to time to evaluate it, but 
> equally we should think carefully before we pull the whole thing to pieces.

Agreed. Its nice from a theoretical perspective to stand and say yes,
there should be all these layers. The reality is a lot of the stack has
fairly tangled and crossed up dependencies.

I'm much more interested to look at things and say "which are the mostly
commonly used pieces of software which a significant number of systems
would use"?

Not every system has a screen, not every system has networking etc. but
there is a common "core" OS which is used in most places and I think
OE-Core should be aiming to provide those basics.

LSB is one guideline we can use for reference of trends. Gut feeling and
experience are other factors that feed into this.

There are then other elements. I'm on record as strongly believing its
not enough to have a software stack, we need to test it too and that
having test capability in the core should be a key value. This isn't
something found traditionally in desktop Linux however it is key to what
we do and we therefore should differ here. (I should explain that by the
fact we allow so much customisation, being able to easily test the
output is important).

There is also another element which is one of the Yocto Project's
objectives. This is to focus people around creating a small number of
good tools rather than many all with some bad points. Its not
specifically an OE objective but OE-Core is a collaboration between OE
and the Yocto Project and I think it should be taken into account (and
is a good thing in general for embedded Linux in general too).

Piglit is interesting in that context since it would be nice to focus
around one way of testing GL rather than having many different ways. If
putting piglit into OE-Core helps that objective then I'm in favour for
that reason too.

So whilst its good to ask the questions, I do think what we have in
OE-Core is pretty good and I wouldn't like to hastily change what seems
to be working quite well at least from where I see it, particularly to
satisfy some "clean" separation idea which looks good on paper but is
less useful in the real world. Regardless of what we do, there are going
to be edge cases and at the end of the day someone has to make a call.
In the case of OE-Core that is ultimately down to me as the maintainer
and the TSC.

We've made choices to remove some things, we've also made decisions to
add others and this will continue and is healthy. With piglit, I'm
leaning more in favour the more I think about it. With meta-qt5 its
still marginal. The wishes of the existing meta-qt5 maintainers need to
be taken into account there too.

The TSC have discussed this before and to one extent or another these
points come up. I'm more than happy for others to add to the list or
correct the above but this is probably as good a description of the core
as you're going to get. Its simply not possible to avoid corner cases
and there always will be some grey areas. Personally I think there are
other things we need to spend time on beyond this.

Cheers,

Richard

Re: Qt in OE-core

[Philip Balister]

On 01/08/2014 06:57 PM, Richard Purdie wrote:
> On Wed, 2014-01-08 at 23:21 +0000, Paul Eggleton wrote:
>> On Wednesday 08 January 2014 13:44:59 Trevor Woerner wrote:
>>> On 01/08/14 10:56, Paul Eggleton wrote:
>>>> However, one concern I have always had with Qt being moved out of
>>>> OE-Core though is that I very much doubt the same will happen with
>>>> GTK+ and GNOME UI components that we carry, which I think will lead to
>>>> the (perhaps erroneous, but logical) assumption in new users' minds
>>>> that we support or recommend these more than we do Qt. Given Qt's
>>>> popularity in the embedded space I don't think this would be the right
>>>> message to be sending out. Any concrete ideas on how we would address
>>>> this perception issue?
>>>
>>> Would it be worthwhile to ask that the OE TSC take on the task of
>>> defining what is "core" and what is not? Does this definition already exist?
>>
>> If we can't come up with a consensus here, then yes. The trouble is one 
>> person's idea of "core" is likely going to be very different to another's. If 
>> your UI is written using Qt, that's going to be core to what you are doing. If 
>> your UI is a custom one written using SDL you won't give two hoots about 
>> recipes for building Qt/GTK+ and everything related. Where do you draw the 
>> line?
>>
>> Although it hasn't been rigorously defined since the beginning and there are 
>> definitely some fuzzy edges, I think the selection of recipes in OE-Core has 
>> worked reasonably well. We should stop from time to time to evaluate it, but 
>> equally we should think carefully before we pull the whole thing to pieces.
> 
> Agreed. Its nice from a theoretical perspective to stand and say yes,
> there should be all these layers. The reality is a lot of the stack has
> fairly tangled and crossed up dependencies.

When making a new layer, we should think hard about what layers it needs
to depends on. Layers should try not to lead to exploding depends.

I am developing a concept in my head of a set of layers it is "safe" to
depend on.

Philip

> 
> I'm much more interested to look at things and say "which are the mostly
> commonly used pieces of software which a significant number of systems
> would use"?
> 
> Not every system has a screen, not every system has networking etc. but
> there is a common "core" OS which is used in most places and I think
> OE-Core should be aiming to provide those basics.
> 
> LSB is one guideline we can use for reference of trends. Gut feeling and
> experience are other factors that feed into this.
> 
> There are then other elements. I'm on record as strongly believing its
> not enough to have a software stack, we need to test it too and that
> having test capability in the core should be a key value. This isn't
> something found traditionally in desktop Linux however it is key to what
> we do and we therefore should differ here. (I should explain that by the
> fact we allow so much customisation, being able to easily test the
> output is important).
> 
> There is also another element which is one of the Yocto Project's
> objectives. This is to focus people around creating a small number of
> good tools rather than many all with some bad points. Its not
> specifically an OE objective but OE-Core is a collaboration between OE
> and the Yocto Project and I think it should be taken into account (and
> is a good thing in general for embedded Linux in general too).
> 
> Piglit is interesting in that context since it would be nice to focus
> around one way of testing GL rather than having many different ways. If
> putting piglit into OE-Core helps that objective then I'm in favour for
> that reason too.
> 
> So whilst its good to ask the questions, I do think what we have in
> OE-Core is pretty good and I wouldn't like to hastily change what seems
> to be working quite well at least from where I see it, particularly to
> satisfy some "clean" separation idea which looks good on paper but is
> less useful in the real world. Regardless of what we do, there are going
> to be edge cases and at the end of the day someone has to make a call.
> In the case of OE-Core that is ultimately down to me as the maintainer
> and the TSC.
> 
> We've made choices to remove some things, we've also made decisions to
> add others and this will continue and is healthy. With piglit, I'm
> leaning more in favour the more I think about it. With meta-qt5 its
> still marginal. The wishes of the existing meta-qt5 maintainers need to
> be taken into account there too.
> 
> The TSC have discussed this before and to one extent or another these
> points come up. I'm more than happy for others to add to the list or
> correct the above but this is probably as good a description of the core
> as you're going to get. Its simply not possible to avoid corner cases
> and there always will be some grey areas. Personally I think there are
> other things we need to spend time on beyond this.
> 
> Cheers,
> 
> Richard
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 

Re: Qt in OE-core

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

On Wed, Jan 08, 2014 at 11:21:08PM +0000, Paul Eggleton wrote:
> > In my opinion...
> > 
> > Personally I would be in favour of removing GTK+ and the GNOME UI from
> > the core and putting them in their own layer for all the same reasons I
> > think Qt should be in its own layer:
> > - a "basic" image doesn't need them
> > - we can have different layers to track separate major releases (as with
> > qt3, qt4, and qt5)
> 
> The trouble is, if you have no toolkit at all, how do you test that X still 
> works properly? The selection we have provides a single unit allowing us to 
> test the entire stack reasonably well without having to add anything else. I 
> think that's a valuable thing to have.

By testing oe-core + layer with X.

Everybody else is using oe-core + couple of other layers, why do we need
to make oe-core testable with X _in single_ layer?

I'm not saying that oe-core should be tested with 30 layers like my
world build, but why cannot AB have special build which builds

oe-core + meta-xorg + meta-gnome

and runs some runtime QA tests on that and then some other build with

oe-core + meta-python

for piglit tests?

Is it limitation of AB scripts for builds that they cannot fetch other
layers so they need everything glued together with combo-layer?

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Qt in OE-core

[Koen Kooi]

Op 9 jan. 2014, om 01:32 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:

> On Wed, Jan 08, 2014 at 11:21:08PM +0000, Paul Eggleton wrote:
>>> In my opinion...
>>> 
>>> Personally I would be in favour of removing GTK+ and the GNOME UI from
>>> the core and putting them in their own layer for all the same reasons I
>>> think Qt should be in its own layer:
>>> - a "basic" image doesn't need them
>>> - we can have different layers to track separate major releases (as with
>>> qt3, qt4, and qt5)
>> 
>> The trouble is, if you have no toolkit at all, how do you test that X still 
>> works properly? The selection we have provides a single unit allowing us to 
>> test the entire stack reasonably well without having to add anything else. I 
>> think that's a valuable thing to have.
> 
> By testing oe-core + layer with X.
> 
> Everybody else is using oe-core + couple of other layers, why do we need
> to make oe-core testable with X _in single_ layer?

I have never seen a good explanation for that

> I'm not saying that oe-core should be tested with 30 layers like my
> world build, but why cannot AB have special build which builds
> 
> oe-core + meta-xorg + meta-gnome
> 
> and runs some runtime QA tests on that and then some other build with
> 
> oe-core + meta-python
> 
> for piglit tests?

And e.g. meta-xorg could live inside the oe-core git repo if additional git repos are too scary.

Re: Qt in OE-core

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

On Wed, Jan 8, 2014 at 10:32 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

> On Wed, Jan 08, 2014 at 11:21:08PM +0000, Paul Eggleton wrote:
> > > In my opinion...
> > >
> > > Personally I would be in favour of removing GTK+ and the GNOME UI from
> > > the core and putting them in their own layer for all the same reasons I
> > > think Qt should be in its own layer:
> > > - a "basic" image doesn't need them
> > > - we can have different layers to track separate major releases (as
> with
> > > qt3, qt4, and qt5)
> >
> > The trouble is, if you have no toolkit at all, how do you test that X
> still
> > works properly? The selection we have provides a single unit allowing us
> to
> > test the entire stack reasonably well without having to add anything
> else. I
> > think that's a valuable thing to have.
>
> By testing oe-core + layer with X.
>
> Everybody else is using oe-core + couple of other layers, why do we need
> to make oe-core testable with X _in single_ layer?
>
> I'm not saying that oe-core should be tested with 30 layers like my
> world build, but why cannot AB have special build which builds
>
> oe-core + meta-xorg + meta-gnome
>
> and runs some runtime QA tests on that and then some other build with
>
> oe-core + meta-python
>
> for piglit tests?
>
> Is it limitation of AB scripts for builds that they cannot fetch other
> layers so they need everything glued together with combo-layer?


I full agree here; this would be more in line of what we communicate to our
users and layers being a good and nice way to modularize the system...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

Re: Qt in OE-core

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

Hello,

On Thu, Jan 9, 2014 at 4:32 AM, Koen Kooi <koen@dominion.thruhere.net>wrote:

>
> Op 9 jan. 2014, om 01:32 heeft Martin Jansa <martin.jansa@gmail.com> het
> volgende geschreven:
>
> > On Wed, Jan 08, 2014 at 11:21:08PM +0000, Paul Eggleton wrote:
> >>> In my opinion...
> >>>
> >>> Personally I would be in favour of removing GTK+ and the GNOME UI from
> >>> the core and putting them in their own layer for all the same reasons I
> >>> think Qt should be in its own layer:
> >>> - a "basic" image doesn't need them
> >>> - we can have different layers to track separate major releases (as
> with
> >>> qt3, qt4, and qt5)
> >>
> >> The trouble is, if you have no toolkit at all, how do you test that X
> still
> >> works properly? The selection we have provides a single unit allowing
> us to
> >> test the entire stack reasonably well without having to add anything
> else. I
> >> think that's a valuable thing to have.
> >
> > By testing oe-core + layer with X.
> >
> > Everybody else is using oe-core + couple of other layers, why do we need
> > to make oe-core testable with X _in single_ layer?
>
> I have never seen a good explanation for that
>
> > I'm not saying that oe-core should be tested with 30 layers like my
> > world build, but why cannot AB have special build which builds
> >
> > oe-core + meta-xorg + meta-gnome
> >
> > and runs some runtime QA tests on that and then some other build with
> >
> > oe-core + meta-python
> >
> > for piglit tests?
>
> And e.g. meta-xorg could live inside the oe-core git repo if additional
> git repos are too scary.


Everyone using OE-Core/Poky in real world end using many GIT repositories
so I don't think it is a problem.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 2722 bytes --]

Re: Qt in OE-core

[Trevor Woerner]

On 01/08/14 05:28, Richard Purdie wrote:
> On Tue, 2014-01-07 at 20:23 +0100, Martin Jansa wrote:
>> With PACKAGECONFIGs which can list optional dependencies which aren't
>> included in the the layer itself it's now easier to have recipe with
>> optional qt5 support in oe-core, but qt5 itself in separate meta-qt5.
> What dependencies on other layers does meta-qt5 have?
>
> If the policy is all qt5 things into meta-qt5, the risk is a fairly
> large set of layer dependencies for meta-qt5.
>
> There is some perception I don't like external layers which isn't true. 
>
> What I do dislike is "dependency creep". If the meta-qt5 isn't usable
> without pulling in chunks of meta-oe for example, I'd think that rather
> sad and it might as well move to meta-oe at that point.

Theoretically, which dependencies a given usage of qt5 has depends on
which PACKAGECONFIGs are used. In other words, one OE image or one OE
distribution might want to use OpenGL, while another might decide
against it.

    http://qt-project.org/doc/qt-5/linux-requirements.html

If we did move to breaking more things out into more layers, would the
resulting increase in the number of layers be easier to manage if we
didn't have to depend on the user correctly setting up their
conf/bblayers.conf? I admit I'm not familiar with a large number of
applications of OE/Yocto, but of the 3 of which I am aware (gumstix,
imx53qsb, and internally at Linaro) all have moved to using repo (an
external tool) and custom initialization scripts to better handle
setting up a user's layers and configuration.[1][2]

What if a distro configuration file, an image.bb, a MACHINE
specification, or a layer could specify its dependencies itself? Would
this lead to "DLL hell"[3] or would this be the missing ingredient which
keeps some projects from having to resort to using external tools?

If a distro has the power to decide which UI library to use on which
backend, should it then be up to the distro configuration to specify
which layer(s) to add, and maybe even which branch/commit to use, and
maybe also specify these layers' priority and ordering? Maybe in a
different scenario this decision wants to be handled by the image
configuration instead. In either case, we wouldn't have to rely on
external tools (repo) and manual intervention (hoping the user updates
conf/bblayers.conf correctly) to get our layers right before we can build.

Same goes for meta-qt5. If meta-qt5 has dependencies on specific other
layers, maybe those dependencies could be part of the meta-qt5
definition such that these other layers are pulled in automatically? Or
maybe a specific choice of PACKAGECONFIG would trigger the required
dependency?

Would it be possible to add a step in the build process that uses
bitbake's fetcher to get or sync a project's layers before starting the
process of fetching a recipe's sources based on information collected
from hints in the various configuration files?


[1]
https://github.com/gumstix/Gumstix-YoctoProject-Repo/blob/master/README.md
[2] https://github.com/Freescale/fsl-community-bsp-platform
[3] http://en.wikipedia.org/wiki/DLL_Hell

Re: Qt in OE-core

[Phil Blundell]

On Thu, 2014-01-09 at 01:32 +0100, Martin Jansa wrote:
> I'm not saying that oe-core should be tested with 30 layers like my
> world build, but why cannot AB have special build which builds
> 
> oe-core + meta-xorg + meta-gnome
> 
> and runs some runtime QA tests on that and then some other build with
> 
> oe-core + meta-python
> 
> for piglit tests?

There's probably no reason that it can't be done.  There are possibly a
few reasons why it might not be a good idea though:

- someone would need to keep track of what version of each layer the AB
needs to be using and update its configuration accordingly;

- there is a risk that you might end up spending all your time chasing
spurious oe-core QA failures caused by problems with those external
layers rather than finding genuine bugs in oe-core itself;

- if either of those layers start depending on something else then you
would need to add those dependencies as well, and so on potentially ad
infinitum;

- if something goes wrong in (say) meta-gnome that starts causing
oe-core testsuite failures then you will be reliant on the meta-gnome
maintainers to fix the problem in a reasonable time.

If you're going to make testing be a first-class part of the oe-core
development cycle then I think you can mount a fairly convincing
argument that the core ought to be testable using only things that are
either inside oe-core or at least under the control of the same
maintainers.

p.