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

[Brian Karcz]

Hi Paul,

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. This wasn't surprising, but I wanted to make sure that there wasn't something being left in the build directory from the main image build that was effecting this.

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. 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?

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.

Thanks,
Brian


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

On Wednesday 31 July 2013 20:27:16 Brian Karcz wrote:
> Here is a little background of what is going on. I inherited a project 
> that was implemented under and works with Edison. The project has two 
> image recipes, abc-main.bb and abc-ramdisk.bb. The way the project 
> builds under Edison, abc-main.bb has abc-ramdisk listed in the DEPENDS variable.
> Abc-main then has an image preprocess command that sneakily goes into 
> the DEPLOY_DIR_IMAGE and retrieves the ramdisk image and inserts it 
> into its own IMAGE_ROOTFS.
> 
> As I've been working on porting to the Dylan version of the build 
> system, I found the whole issue with do_fetch and do_unpack not being 
> run at all for images. I applied the fix you advised of to add a 
> python function that removes the noexec flag for the two tasks. This 
> apparently only works for one build of the image. I either need to do 
> a "cleanall" on the image or bump the rev to get it to build again.

I haven't had time to try to reproduce this here yet, sorry.
 
However, aside from the files in SRC_URI which could presumably be handled in a separate recipe, one possible solution for the ramdisk part did occur to me - I'd suggest doing the following in the main image:

do_rootfs[depends] += "abc-ramdisk:do_rootfs"

Then add to ROOTFS_POSTPROCESS_COMMAND or IMAGE_POSTPROCESS_COMMAND (whichever is appropriate) a call to a shell function that performs whatever needed operation on the abc-ramdisk.

> Another interesting note that might be of interest is that our LICENCE 
> is defined to "XYZ" and issues the following warning, "WARNING: 
> abc-ramdisk: No generic license file exists for: XYZ in any provider", 
> in the first build that succeeds.

I'm no expert on this area but to me it doesn't make sense for an image containing multiple differently-licensed components to have a declared license in the recipe. We tend to keep things simple and just set LICENSE = "MIT" on the image recipe (*not* implying anything about the contents of the image), with each installed package license and therefore the image's license manifest indicating all of the licenses of the components that make up the image. 
Perhaps a LICENSE value of "N/A" for the image would be more appropriate, although the system currently doesn't support any special casing of LICENSE for image recipes, and if you are pulling in files in SRC_URI in the image recipe there might be some validity to having a LICENSE value to apply to those.

> When the second build is run the warning does not appear and the build 
> jumps right to the do_rootfs task where it fails.

That's because this check is done in do_populate_lic which isn't getting re- executed on the second time (presumably because nothing that that task depends upon has changed).

Cheers,
Paul
 
-- 

Paul Eggleton
Intel Open Source Technology Centre