Re: [OE-core] Qt in OE-core
On Wed, Jan 8, 2014 at 10:32 PM, Martin Jansa martin.ja...@gmail.comwrote: On Wed, Jan 08, 2014 at 11:21:08PM +, 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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
Hello, On Thu, Jan 9, 2014 at 4:32 AM, Koen Kooi k...@dominion.thruhere.netwrote: Op 9 jan. 2014, om 01:32 heeft Martin Jansa martin.ja...@gmail.com het volgende geschreven: On Wed, Jan 08, 2014 at 11:21:08PM +, 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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
Hello folks, On Tue, Jan 7, 2014 at 5:23 PM, Martin Jansa martin.ja...@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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On Wed, Jan 08, 2014 at 03:56:04PM +, 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.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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
Re: [OE-core] Qt in OE-core
On Wed, 2014-01-08 at 23:21 +, 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On 01/08/2014 06:57 PM, Richard Purdie wrote: On Wed, 2014-01-08 at 23:21 +, 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
Re: [OE-core] Qt in OE-core
On Wed, Jan 08, 2014 at 11:21:08PM +, 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.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
Op 9 jan. 2014, om 01:32 heeft Martin Jansa martin.ja...@gmail.com het volgende geschreven: On Wed, Jan 08, 2014 at 11:21:08PM +, 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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
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.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
