Qt in OE-core

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

Quoted 23 lines · 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?

Quoted 6 lines

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.

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.

Hi all,

Quoted 18 lines · 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?

Quoted 6 lines

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?

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?

Quoted 8 lines · Paul Eggleton

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?

Quoted 8 lines · Paul Eggleton

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

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?

Quoted 10 lines · On Wednesday 08 January 2014 13:44:59 Trevor Woerner wrote:

Quoted 8 lines · Paul Eggleton

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?

Quoted 2 lines

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.

Quoted 21 lines · Paul Eggleton

Quoted 10 lines · On Wednesday 08 January 2014 13:44:59 Trevor Woerner wrote:

Quoted 8 lines · Paul Eggleton

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?

Quoted 2 lines

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?

Quoted 4 lines

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

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 8 lines

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.

Quoted 9 lines

Quoted 8 lines

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)

Quoted 4 lines

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?

Quoted 7 lines · Paul Eggleton

Quoted 7 lines

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

Quoted 3 lines

Quoted 1 line

qt3, qt4, and qt5)

The trouble is, if you have no toolkit at all, how do you test that X

still

Quoted 1 line

works properly? The selection we have provides a single unit allowing us

to

Quoted 1 line

test the entire stack reasonably well without having to add anything

else. I

Quoted 1 line

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?

Op 9 jan. 2014, om 01:32 heeft Martin Jansa <[email protected]> het volgende geschreven:

Quoted 8 lines · Paul Eggleton

Quoted 7 lines

Quoted 7 lines

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

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

qt3, qt4, and qt5)

The trouble is, if you have no toolkit at all, how do you test that X

still

Quoted 1 line

Quoted 1 line

works properly? The selection we have provides a single unit allowing

us to

Quoted 1 line

Quoted 1 line

test the entire stack reasonably well without having to add anything

else. I

Quoted 6 lines

Quoted 1 line

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

Quoted 5 lines

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

Quoted 5 lines

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.

Quoted 3 lines · Martin Jansa

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.

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?