Hi Dave, Thanks for reading the documents and ask some good questions. Answers inline.
On 04/05/2015 23:03, "Lerner, Dave" <[email protected]> wrote: >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? Good question. The list of image recipes to choose from will be based on the layers you have added to your project: basically, it will be a list of all the image recipes provided by the layers you have added to your project. If I understand your question correctly, you are asking if I will be able to select an image recipe I've created before as my starting point. I see no problems with that from a design perspective. I am not sure from the implementation standpoint if this will create difficulties. > >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?) Great question again. For the first version of the functionality, it'll probably be just a flat list of packages. That flat list of packages will include package groups, but you will not be able to see what's inside those package groups. Having said that, package classification is something we should really do later on. How? I am not sure. As you say, such classification might be connected somehow with package groups. So we either create package groups that make sense to people, and give the ability to check what's inside them; or we'll risk ending up with a classification criteria and also a set of package groups, which could be confusing. > >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? Both. You will be able to edit the package list using the web workflow. But your changes will be reflected in the custom image recipe's bb file, which you can download and include in a custom layer. > >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? We can provide a pretty good list of packages by just parsing the layers, which is must faster than building. Because there are dependencies that can only be worked out at build time though, the data from the parsing process might not be 100% accurate, but it should be accurate enough for most customisation work. > Is it impractical to prebuild, then preload the database with package >dependencies for a few standard oe images and downloadable bsps? When would that 'prebuilding' happen? Can it be stopped? My worry is about people just trying Toaster locally, in machines that are not very powerful and can take ages to build things. If we need to do this 'prebuilding' when you set up Toaster, and you cannot stop it once it's started, that can cause trouble. > >page 6 'add a populated state diagram' >I don't understand what is in the 'image files' column? Are those 4 >different image types? Sorry, the sketch is not very clear. All it's trying to indicate is that we need to provide a way for users to download the root file system files produced when you build a custom image recipe. How that will be done exactly will be worked out during the next design phase, when we'll be looking at things in much more detail. > > >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"? The example I was given was a recipe with a post-install script that does something after the image is created. > >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. If you want to add package A to your image, and A depends on package B, B will also have to be added to your image: there is no way around it. That's what we meant by "compulsory". >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? I am totally the wrong person to explain this dependencies business: it makes my head spin :) Maybe Paul or Alex can help? As I mention in the document, we might find that the whole concept of 'optional' vs 'compulsory' dependencies for removal is way too much trouble, and just provide information about what will be removed due to dependencies when you delete a certain package from the list. You can then decide if you want to proceed or not. Cheers Belén > >Dave > -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
