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