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

[Brian Karcz]

Hi Paul,

I commented out all the noexec flag settings in image.bbclass and the results are still the same.

I was starting to get the suspicion that all of that content needed to be moved to a separate package recipe. I'll experiment with that and see where I get. Hopefully that, combined with the information about the checksums you gave me on the other thread can get me back to where we are with Edison, but in a more standardized fashion.

Thanks,
Brian


-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton at linux.intel.com] 
Sent: Thursday, August 01, 2013 10:27 AM
To: Brian Karcz
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] Image recipes in Yocto 1.4 (dylan-9.0.0)

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