The recipes for building images for qemu append their own values to the IMAGE_FSTYPES variable during the build, to ensure that the correct image types are generated to support the qemux86 machine. This is done via qemu.inc with: IMAGE_FSTYPES += "tar.bz2 ext4" If a user edits the IMAGE_FSTYPES variable for their project, then builds a qemu image, they will get more image files than they may have been expected. For example, if the user has set IMAGE_FSTYPES to "ext3", they will actually get images for ext3, ext4 and tar.bz2. We need a warning on the IMAGE_FSTYPES variable (and possibly all project variables, as a recipe could amend any of them) that "bitbake recipes may modify variables during the build, e.g. to ensure required image types are built" (or something to that effect). And/or we could provide an option allowing a user to force the use of their project setting, ignoring any overrides/appends that recipes may attempt. This should come with a warning that this might break builds (if we let the user do it at all). We could then implement this by appending _forcevariable to the variable names when they a written to <build dir>/conf/toaster.conf by localhostbecontroller.triggerBuild().
This is related to bug 7234, in that it is about unexpected differences between variables as they are in the build and how they were set in the project. However, the solution suggested here is to put in place a warning for now, which is a quick fix for the issue of obvious differences between project config and outputs (e.g. where the image files shown are blatantly at odds with IMAGE_FSTYPES). Most other variables which can be changed during the build have a less immediate impact on the build outputs. We can come back to implementing the full variable history (as in bug 7234) at a later date.
To be honest, I rather don't do this. It will create more noise in the UI and it won't solve the problem in any way. The issue is that variables can be set in different places in the metadata through different types of operators, and that it is hard for users to work out how a variable ends up with the value it has. This becomes particularly bad when a value you explicitly set (for example, in local.conf or in Toaster) gets changed. The problem is not exclusive to IMAGE_FSTYPES: as far as I understand, this can happen with pretty much any variable. Pointing just the fact for IMAGE_FSTYPES is somehow misleading. The solution is to provide better visibility and control of the variable setting process in Toaster. There is not a single thing that will fix this: I think we have identified several so far 1. As you mention, improving the presentation and content of the variable history (bug 5811) 2. Exposing BitBake operators in the BitBake variables page, so that you can choose how strong or weak your assignment is 3. Notify users when the value of a variable they have set via Toaster was changed during the build (bug 7234, bug 6900, bug 7235) 4. Provide a way of comparing builds (bug 6840) We are pretty much blind to messages in GUIs: we are too busy doing things with them to be reading text. In this case, I am not sure more text in the UI will help people understand what's actually going on.