> > OK, it turned out that prepending the space before lib32-connman does > > not do any good. However, commenting out the line which contains the > > IMAGE_INSTALL_append does. That begs the question; what does > > lib32-connman do? > > It's not lib32-connman that's the problem. The problem is that you were > effectively setting the value of IMAGE_INSTALL to something and the default in > core-image.bbclass is being set with ?= , and because it's already set at the > time > the ?= is parsed, the defaults (including the chain leading to > sysvinit/systemd) are not being added, among many other packages. If you use > IMAGE_INSTALL_append rather than IMAGE_INSTALL (or use a proper image > recipe instead of appending to IMAGE_INSTALL from local.conf) you shouldn't > have a problem.
You can't use IMAGE_INSTALL_append from local.conf (as you already confirmed). You will have to "use a proper image recipe" (as Paul Eggleton also suggested). I too ran afoul of this recently. The Yocto layer/configuration composition is non-intuitive. It is easy to expect items in local.conf to 'override/extend' the configuration resulting from your layer selections in bblayers.conf, but this is not what happens. I'd personally prefer local.conf to be processed AFTER the conf/layer.conf and conf/machine/some-name.conf files, but at the very least bb needs to know the selected machine first. So to tune/tweak things you need a file up front (local.conf) and a file at the other end (a custom recipe and/or layer). Also, don't think that the ordering of layers in your bblayers.conf file (alone) determines the overlaying/replacement of matching bb/bbappend, inc, or source/patch files. ________________________________ Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation. -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
