[Toaster] Toaster] [RFC] Image customisation with Toaster

Lerner, Dave dave.lerner at windriver.com
Mon May 4 15:03:49 PDT 2015


Hi Belen,

I had some questions on image customisation.

On page 4 Figure 3 Select your image recipe:
You will be able to base your new image on a previously defined image names as well as the yocto stock image names?

page 4 figure 4, Add/remove packages
Will there be a higher grouping to the view of available packages, perhaps by functionality (for example: devtools, graphics, bsps) or layers, meta index,  or will it just be a flat list of package names? (does this relate to the package groups discussed on the final page?)

page 4 figure 5, Once you are done
You note being able to 'edit' the installed package list at any time.  Will this package list be a file, or are you referring to the web workflow?

page 5 Step 2
"The information we display to users during the customisation process can have different degrees of accuracy, depending on the layers that have been parsed and the project build history. Users should be able to parse the project layers, or to build their selected image recipe, if they want a higher degree of information accuracy."

If they are adding packages, the last sentence means that they have to, at least once, build a superset of what they want to cherry-pick, correct?  Is it impractical to prebuild, then preload the database with package dependencies for a few standard oe images and downloadable bsps?

page 6 'add a populated state diagram'
I don't understand what is in the 'image files' column?  Are those 4 different image types?


page 9
It's beyond scope but can I what are the options that "Paul Eggleton has brought up that image recipes might include ... beyond the package list"?

page 10
" Compulsory package dependencies are shown just for information purposes (you either proceed or not).

Optional package dependencies list the packages associated with a check box (like layer dependencies do), that users can uncheck.

->All dependencies when adding a package are compulsory. <-"

I don't understand this statement. It implies that optional packages are compulsory which requires you to define what you mean by optional.  The discussion on removed package dependencies didn't clarify it for me.

In the removal package dependency notes, in the {A->B->C ; C->D} diagram, if you remove A, then B is optional, but what about C and D, are they also optional and by default checked?  Would a full tree visualization make this easier?

Dave



More information about the toaster mailing list