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

[Barros Pena, Belen]

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
>