Hello William, Christopher, Thanks for the detailed explanation.
On Wed, 2012-02-01 at 11:50 -0500, William Mills wrote: > I am not sure I can give you a better option that local.conf but I can > explain why what your doing does not work. > > It may feel from your usage that the image recipe is the ancestor of > all the recipes but this is really not true. The settings in a image > recipe effect the assembly of that image and not the packages that > they depend on. An image could be assembled from packages that were > built long ago or inherited via shared state. > > settings in local,conf on the other hand affect all recipes. If you > add something there it will be seen by all recipes. Unfortunately > this means that all recipes are dependent on the settings and > everything will need to be rebuilt in case the new setting effects > them. I believe this also means you will not be able to used share > state with someone with a different setting of (or unset) > SOME_VARIABLE. (Well you can but you will both be rebuild > everything.) > > Alternatives to the whole approach are to make alternative packages > for the various cases (busybox-minimal vs busybox-full) or use an > image task to create an asset in the file system that then makes a > difference at run time. My use-case is that I am creating an /etc/fstab file via base-files.bbappend recipe. In that fstab, I use uuid (generated via uuidgen) to denote different partition filesystems. So, I have to use this uuid in the extended image_types.bbclass file to set them to the generated partition images appropriately (via tune2fs). One more approach I can think of is to echo the uuid to some file in the deploy images directory (while creating the fstab file) and read them back in image_types class. But this process looks messy. Regards Joshua -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in
signature.asc
Description: This is a digitally signed message part
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
