Th current design for Toaster's project creation feature allows the ability to add and manage layers and configuration variables, but it does not include adding recipes.

This is an important feature since customers will definitely want to add additional YP (and custom) recipes as their project matures, and not supporting this in the Toaster interface requires the user to go to the command line and/or manually edit the "local.conf" values.

Here is proposed support for "adding recipes" to projects, as per the email thread on this subject.

1) The fundamental configuration variable I am discussing it this. It is the fast and easy way for the developer to add additional recipes to their build without manipulating images. It is easy to add and remove recipes from this variable without side effects (aside from the resulting generated target of course), and bitbake can easily resolve and add dependencies on the fly.

"local.conf":

  IMAGE_INSTALL_append = " my-recipe"

2) My proposal is to make this configuration variable a special case, in that it is relatively easy for Toaster to provide guidance to adding and removing recipes from this value.

3) As Alex described, the "official" recipe list is not really available until the first build, and even then it is approximate and gains accuracy after each build.

However, we can as a heuristic still provide the developer a pull-down list with a new un-parsed project a reasonable list of "possible" recipes, derived simply by examining the list of registered layers and including all recipes physically present in those layer directories. We can then improve that list after each build iteration with the parsed and derived recipes from bitbake.

We can perhaps even distinguish "possible" recipes by displaying them in italics, and bitbake's "sanctioned" recipes in regular type. This leaves the world of recipes open to the developer but does provide guidance as to preferred recipes.

4) Removing recipes that are part of the image (in other words going "negative") I agree is very complicated and out-of-scope of this release. That is why I am limiting this instance to the specific local.conf variable.