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

[Barros Pena, Belen]

On 05/05/2015 20:07, "Lerner, Dave" <dave.lerner at windriver.com> 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:belen.barros.pena at intel.com]
>> Sent: Tuesday, May 05, 2015 1:34 PM
>> To: Lerner, Dave; toaster at yoctoproject.org
>> 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" <dave.lerner at windriver.com> 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
>> >
>>
>