On 05/05/2015 20:07, "Lerner, Dave" <[email protected]> wrote:
>Belen, >> >> > 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. > >By prebuilts, I meant that it would be done before release on a few major >bitbake image targets for some selection of bsps during the yocto release >build process, that is, by the yocto team. This dependency list would be >part of the yocto distribution that helps populate toaster tables. I see. This sounds like a question for Paul Eggleton. We'll see what he thinks. Cheers Belén > >> -----Original Message----- >> From: Barros Pena, Belen [mailto:[email protected]] >> Sent: Tuesday, May 05, 2015 1:34 PM >> To: Lerner, Dave; [email protected] >> Subject: Re: Toaster] [RFC] Image customisation with Toaster >> >> 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
