On 11/07/2014 08:16, "Reyna, David" <[email protected]> wrote:
>I am flexible about this wording - I just wanted to bring this question >to your attention. Fair enough. If you can think of something better, do let me know. It can be tricky to get the labelling right > >I am trying to fully understand your words and assumptions. What is your >"Imported layer source"? Is that an object separate from the user's layer? My explanation might not be technically accurate, but in my head a layer source is a collection of information about a set of layers, not the layers themselves. Because one of the pieces of information in the collection is the layer repository, once a layer from a collection is added to a project it can be cloned when you start a build. Now, this git repository I guess can live anywhere accessible to the build hardware: in a public server or service (e.g. Github) or in a server inside your organisation. So the "Imported" layer source is the collection of information about the layers imported by users. Like other layer sources, it can be searched and filtered, and layers from it added to projects. >When you write "effectively that imports the layer information" are you >implying a physical copy or just a logical reference? I think it's a logical reference (i.e. a set of information about the layer that allows the build system to clone it). Looking at http://layers.openembedded.org might give you an idea of what I mean. > >In the call you mentioned that you expected that the imported layers >would be in a bare git clone format. While this is true for the >distribution content, I want to mention again that we expect customers >will have their custom layers in a normal directory format since they >would be under active development and not compressed into a repo. We >need to support both formats. This opens up all kinds of interesting questions regarding development workflow. In principle, when Toaster is running in the same machine that runs the builds, it seems simple to allow people to browse the directory structure when importing a layer and select a local layer directory. But this opens up other problems. For example, we will allow people to export projects to be shared with other people, but if you are using a layer that only exists locally in your computer, the sharing paradigm breaks. If we assume that the main use case for Toaster is within an organisation where several people will work together and be jointly responsible for distro work, enforcing the use of repositories as a way to share layers might be a reasonable thing to do. I could be wrong though. > >BTW, this brings to mind a related question. Is it the assumption that >any imported layer must exist both on the host (so that it can be parsed) >but also at the remote build machine (so that the builder can use it)? If >not, does this indeed imply a copy action of the layer to that remote >builder? What is our plan and guidance to the users here? I believe the layers will just be cloned in the remote build machine as needed. Alex should be able to confirm this. Cheers Belén -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
