Right now, we import all the layers from http://layers.openembedded.org/ . Unfortunately, some layers require setup that toaster is not able to do. An example (the only one I have right now) of this is meta-debian. From the meta-debian github readme: How to bitbake ============== export TEMPLATECONF=meta-debian/conf Setup repositories $ git clone git://git.yoctoproject.org/poky.git $ cd poky $ git checkout daisy $ git clone https://github.com/meta-debian/meta-debian.git $ cd meta-debian $ git checkout daisy - So, this one isn't buildable by toaster. I'd rather have a generic exclusion list in the config file so that it is useable by others.
Leaving other practicality issues of meta-debian aside, I doubt you absolutely have to do it the way they describe - TEMPLATECONF is just a means of setting up a default local.conf; you can just as easily look at the template and set the desired config values in the project configuration.
3 issues I see 1) following the instructions in meta-debian worked for daisy, but not master. There's no branch support in meta-debian for fido or dizzy. This means that it doesn't work with any revision that toaster supports 2) even for daisy, meta-debian requires that it be checkout out into the poky dir which is not a supported configuration for toaster. 3) From a philosophical perspective, I expect that if a user adds a layer in toaster and then tries to build a recipe from it that it *should* work. It's a ui tool to reduce the complexity. We effectively have 2 choices: a) to build meta-debian you remove it from the exclusion list, fixup the variables by hand, and move the layer once it's checked out. Complex but would probably work. This way only users who really know what they are doing would be doing it. b) all users who happened to be looking for a recipe and saw it in meta-debian could add that layer (this might be very common since debian is probably the most familiar word in the list). all builds would then fail with a set of complex errors. I prefer to set up UI's so that the common actions work. If you really need to do something out of the box (remove meta-debian from the exclusion list for example) it's possible but only advanced users with a need for it would. Otherwise it's more like setting up a trap. Since toaster (if used) makes adding arbitrary layers VERY easy, we are implicitly saying we think they should work when added. Leaving in ones we know cannot work without extra "by hand" workarounds is unacceptable unless we add caveats in the layer adding code that says "must do Y before the build will succeed"...
Sure - I accept the point about having something that's expected to work. This is the kind of the worry I had early on about making it trivially easy to add layers from the layer index (Belen may remember that discussion). I'd rather not rely on hardcoded exclusion lists though - if there's some data to be recorded about how these layers should be used or not used, it should be in the layer index itself. Based on what you've found, what it sounds like to me is that meta-debian probably shouldn't have a master branch record so it doesn't show up under master. In order to fix that though we are going to have to ensure that people can still reasonably find layers they are looking for in the layer index without having to flip through all of the branch options (assuming they even realise branch is selectable). That's a problem with the layer index UI rather than Toaster however. The issue of branch compatibility is an ongoing one - bug 7220 relates to this.
I'm not sure how bug 7220 relates. As far as the hardcoding issue, I don't see it as hardcoded when it's part of a configuration file. For example, I can imagine a company making their own layer index to serve their layers and wanting to have a couple of layers that they know are compatible from layers.openembedded.org appear as well. This would be another way to use the exclusion list. I guess I'm envisioning a number of different configuration files being used by different people and the exclusion list could be used to tailor UI's as well as dropping things that don't work for the branches we care about.
(In reply to comment #4) > I'm not sure how bug 7220 relates. I think Paul might have meant bug 7792 Paul: "In order to fix that though we are going to have to ensure that people can still reasonably find layers they are looking for in the layer index without having to flip through all of the branch options" We could provide some search options for the layers: 1. Select a branch to search 2. Search across all branches 2 could be the default. That would require adding a 'branch' column to the layers table. "(assuming they even realise branch is selectable)." Mmm, it sounds as if you have evidence that people do not see the branch control. That can be easily fixed. Showing the branch in a standard dropdown menu instead of the caret we are using right now will probably do the trick.
Yes I definitely meant bug 7792, not sure what happened there. Perhaps "hardcoded" isn't really the right word - what I mean is that you're holding information about something external that is not under our control and may change. This is less about Toaster than it is about how the layers are meant to be used, and I feel it is much better to record information about that in the layer index itself and then we can read it from there - the layer maintainer changes in the layer, then the meta-information can be changed much more easily by them in the layer index (or in some cases it might be able to be updated automatically the next time the layer index update script runs). Regarding the layer index UI - I don't have any evidence really, I just have a suspicion that most people look at master; even if they select the correct branch, there will be layers out there that might be usable that won't show up because they don't have a branch record for the selected branch. The "all branches" option might work but then we'd have the problem of what to show for the branch-specific info (most significantly when we consider the layer details page or recipe listings etc.)
There are 2 complementary goals here, i think. In the case of "is this layer compatible with release X" I agree that it would be nice to keep that information in the layerindex so it is all available in the same place and has the advantages you outlined. The main advantage of an exclusion list is that it allows 1) a group/company wanting to customize or limit the layers that their instantiation of toaster shows without forcing them to host their own layer index. 2) allows a group/company to respond to a change in the layer index that breaks their stuff by changing something under their control allowing for quick turnaround. 1) is an enhancement and would possibly never be used, so I'm ok with dropping it. 2) is more what I was hoping to address with an exclusion list. I can live with no exclusion list if we can get a metadata mechanism into layerindex so we can turn off incompatible layer/release combinations.
I don't have a major objection to an exclusion list for the purposes that you outline, but IMO it shouldn't be used out of the box to solve the problem that triggered the opening of the report. Having said that with all that is going on I don't think we will get to implementing the layer index method in time for the upcoming release.
agreed. Both the long term goal and the short term workaround.
No longer relevant. YP Compatible flags/markup in layers.openembedded should be reflected into Toaster's UI. This is a fairer approach. Closing.