[yocto] Image recipes in Yocto 1.4 (dylan-9.0.0)

[Paul Eggleton]

On Thursday 01 August 2013 14:00:24 Brian Karcz wrote:
> I'll keep the do_rootfs dependency adjustment for the main image on ready.
> I'd like to try to fix the simple case first of only building the ramdisk
> image directly then trying to rebuild it. With the latter case fixed, the
> former might be fine as is.
> 
> As a sanity check last night, I blew away the entire build directory and
> only built the ramdisk image recipe. I wanted to make sure there was
> nothing left in there from a main image build that might be effecting an
> explicit ramdisk image build. This overnight build succeeded. When I
> performed the rebuild this morning, the same behavior occurred of the
> IMAGE_PREPROCESS_COMMAND not being able to find a file in the WORKDIR.
>
> Sorry for the confusion about the license data. I wasn't interested,
> necessarily, in the content or cause of the warning, but more the task flow
> of the build that was causing the warning to appear in one build and not
> the other. I wasn't sure if the do_populate_lic dependency change might
> trigger any thoughts on the do_fetch dependencies.
> 
> One thing I had a question about was in regards to image vs package recipes
> and the population of the rootfs. Package recipes populate the rootfs by
> appending/prepending the do_install task and install things from the
> WORKDIR to the $D destination directory. 

To be completely accurate, they don't populate the rootfs directly, they 
install files into the ${D} directory (${WORKDIR}/image) during do_install, 
then do_package creates package definitions from this, then do_package_write_* 
create the actual packages based upon the definitions, and then later when the 
image is constructed some subset of those packages may be installed into the 
rootfs.

> Our image recipes, as I've inherited them, create and assign a new
> IMAGE_PREPROCESS_COMMAND, that install files from the WORKDIR to the
> IMAGE_ROOTFS destination directory. Is it abnormal/non-standard for an image
> recipe to have its own SRC_URI entries and subsequent WORKDIR population?

It is considered so, yes. We disabled this functionality by default in the 
denzil release (1.2) on the assumption that image recipes shouldn't really be 
doing this - additional files that need to be pulled in should be pulled in via 
packages created by a separate recipe. It's perfectly fine for the image to be 
modifying or creating small files from scratch particularly if they're 
constructed from dynamic data, but bringing in extra static files should really 
be handled via additional packages.

> I'm wondering if there is a catch-22 going on here regarding the use of
> RM_WORK and the fact that the checksums for the SRC_URI contents haven't
> changed. It seems as though the build is determining that do_fetch doesn't
> need to be run because nothing is changed, like in a package recipe, but
> doesn't realize that do_rootfs will always be executed for an image recipe
> build and might depend on those contents. I'm wondering if this worked
> under Edison because it didn't have the SRC_URI checksums and a different
> dependency model that forced the do_fetch prior to do_rootfs for image
> recipe builds.

Could you run a test for me - if you comment out the setting of noexec on all 
of the tasks at the end image.bbclass does the rebuilding problem go away?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre