Right now we allow people to import a layer with the same name of an existing layer. The information provided creates a new layer version in the database. The new layer version replaces the old layer version in the list of compatible layers. This, however, is transparent to users. In the interface, it looks like they are importing a new layer, and users are therefore likely to expect to see both layer versions listed as separate layers in the compatible layers list. As as example, I have a project x that uses the dizzy release. There, I have an openembedded-core layer coming from the poky git repo with revision dizzy. If I then import a layer called openembedded-core from the poky git repo but I specify master as the revision, my old dizzy revision is replaced by the new master revision. When I visit the list of compatible layers for project x, I don't see openembedded-core dizzy and openembedded-core master: I just see openembedded-core master. I have effectively edited the layer revision, while Toaster has been telling me that I was importing a new layer. Toaster has cheated on me somehow. There are a couple of ways we can address this issue, but none of them can be done within this release. So, as an interim solution, and for the sake of clarity, we should consider not allowing people to import layers with the same name as existing layers, i.e. we should enforce the rule that layer names, within the context of a project, must be unique. Thoughts?
I wouldn't recommend making any changes to the import layer mechanism. The programmatic logic flow is coupled with the design, there is an assumption that we can update an existing layer, which includes all the error messages and checks/validation. (See the flow in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/toaster/toastergui/views.py#n2388 and page 9 of your design document https://bugzilla.yoctoproject.org/attachment.cgi?id=2286) The only interim suggestion I can think of would be to have a description at the top of the import page saying something like "If we find an existing layer we will attempt to update it with the new values"
(In reply to comment #1) > I wouldn't recommend making any changes to the import layer mechanism. Why?
got my answer: logic is fiendishly complicated. After a very long discussion, we have identified 2 main problems: 1. When you import a layer that has the same name and git url of an existing layer, you are effectively updating that existing layer with the information you provide in the import layer form, but the interface does not explain this to you in any way 2. When you update a layer's revision using the process explained above you can no longer select the old revision, even though it is in the database. The only solution if you want to go back to the previous revision is to override the revision again, which is pretty clunky. We will address the above problems in 2 stages: Stage 1, covered by this bug, will implement some changes to the import layer page to communicate to users that when you import a layer with the same name and git url of an existing layer you are basically updating the layer information Stage 2, covered by bug 6640, will add a way to view and select which revision to build of all the ones that exist for a certain layer.
Created attachment 2424 [details] Design - Changes to the import layers page Explains the suggested changes
commit dcbfc74c3ce9b69c020ed18ae42b8b27f8dc3991 (Bitbake rev: 4590cfcb2d5e26518e04f8abc8e7c2dad973f6d2)
Created attachment 2888 [details] layer For a layer name that matches an existing imported layer name within the current project the subdirectory is not displayed even if it's not blank. This happens on master too.
Created attachment 2889 [details] layer details Put this on reopened.
Sorry, reopened.
(In reply to comment #6) > Created attachment 2888 [details] > layer > > For a layer name that matches an existing imported layer name within the > current project the subdirectory is not displayed even if it's not blank. > > This happens on master too. This seems quite a small problem, since the most important information about the layer (the git uri and the revision) are shown, and users are provided with a link to the full layer information. It is a bit harsh to reopen this bug because of this issue, so I am going to close it (mainly because we don't have manpower to tackle this small things... I wish we did).