[yocto] Extending images

[Christopher Larson]

On Fri, Jul 18, 2014 at 11:45 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:

>
> > On 2014-07-18 10:49, Christopher Larson wrote:
> > >
> > > On Fri, Jul 18, 2014 at 9:26 AM, Gary Thomas <gary at mlbassoc.com
> > > <mailto:gary at mlbassoc.com>> wrote:
> > >
> > >     've always used 'IMAGE_INSTALL += " xyz"' in my local.conf
> > >     to add new packages to a build.  That said, I had a working
> > >     build for qemuarm (probably doesn't matter) and I added:
> > >        IMAGE_INSTALL += " strace"
> > >     This produced a completely broken image which barely came
> > >     up to a shell, lots of missing programs, etc.
> > >
> > >     I then tried
> > >        CORE_IMAGE_EXTRA_INSTALL += " strace"
> > >     which produced a perfectly working build (just as previous)
> > >     with the new package added.
> > >
> > >     I can see that the images produced are vastly different:
> > >
> > >     * Original working build
> > >     -rw-r--r-- 1 gthomas gthomas     11719 Jul 18 09:34
> > >     core-image-sato-qemuarm-__20140718124453.rootfs.manifest
> > >     -rw-r--r-- 1 gthomas gthomas  87611203 Jul 18 09:34
> > >     core-image-sato-qemuarm-__20140718124453.rootfs.tar.bz2
> > >
> > >     * After 'IMAGE_INSTALL += '
> > >     -rw-r--r-- 1 gthomas gthomas      9986 Jul 18 09:55
> > >     core-image-sato-qemuarm-__20140718155134.rootfs.manifest
> > >     -rw-r--r-- 1 gthomas gthomas  37859884 Jul 18 09:56
> > >     core-image-sato-qemuarm-__20140718155134.rootfs.tar.bz2
> > >
> > >     * After 'CORE_IMAGE_EXTRA_INSTALL += '
> > >     -rw-r--r-- 1 gthomas gthomas     11738 Jul 18 10:05
> > >     core-image-sato-qemuarm-__20140718160108.rootfs.manifest
> > >     -rw-r--r-- 1 gthomas gthomas  87720106 Jul 18 10:05
> > >     core-image-sato-qemuarm-__20140718160108.rootfs.tar.bz2
> > >
> > >     What's the difference and why did the first attempt fail?
> > >
> > >
> > > Most likely the image defined its own IMAGE_INSTALL using ?=, so
> > > defining it yourself in the configuration data overrode its
> > > default definition, since ?= is "set only if unset". If the recipe
> > > didn't use ?=, then your IMAGE_INSTALL += would have had no effect
> > > at all. To append to IMAGE_INSTALL directly without using
> > > CORE_IMAGE_EXTRA_INSTALL you could have used IMAGE_INSTALL_append,
> > > since that's a postponed operation that happens at the end of the
> > > recipe parsing.
> >
> > That makes sense, thanks.  I'll stick to using
> > CORE_IMAGE_EXTRA_INSTALL from now on!
>
>   not to sound repetitively repetitive, but this is related to what i
> thought was the weird way core images are defined based off of
> core-image.bbclass, where core-image.bbclass does *exactly* what you
> describe above:
>
> CORE_IMAGE_BASE_INSTALL = '\
>     packagegroup-core-boot \
>     packagegroup-base-extended \
>     \
>     ${CORE_IMAGE_EXTRA_INSTALL} \
>     '
>
> CORE_IMAGE_EXTRA_INSTALL ?= ""
>
> IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"
>
>   the danger here is that if someone has been defining/building images
> for a while based off of the lower-level image.bbclass, then (i think)
> using "IMAGE_INSTALL +=" will work just fine, and the poor developer
> gets lulled into a false sense of security and carries that habit over
> to her first core-image and ... boom.
>

I really don't think this was ever safe, as it completely depended on how
the image recipe added its bits to IMAGE_INSTALL, which could easily vary
from image to image. I've *always* told folks to use IMAGE_INSTALL_append
if anything, even back in oe classic :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140718/4ad1723b/attachment.html>