Hi, This is something that came up in a conversation with Koen and I thought it might be prudent to open the debate on the list to get some feedback about the best way to approach this workflow without generating any ill feeling or unintentional marginalisation.
The scenario is quite simple... I have started to clean up and refactor the old OpenPandora recipes into something that aligns a lot more closely with OE-Core/Meta-OE and Meta-Angstrom going forward. This is purely a personal project (that I welcome help with) and is not necessarily tied to the main OpenPandora 'entity'. It is mostly for my own benefit as I have a few other projects/machines that I would like to apply the same working pattern. The forking and keeping bits in various trees with no very clear distinction has always been a problem in the past and I want to minimise this going forward making best use of layers. I also want to ensure some ground rules are set before I start committing or working on this in earnest (it's a 'free time pet project' for me so I don't want to waste my time creating a rod for my own back, I can do that on a myriad of other projects ;)). At the moment I have https://github.com/openpandora/meta-openpandora, this is the old OpenPandora overlay refactored into something more akin to the new layer layout. At the moment this layer has both machine level BSP type stuff in it and the general 'not for mainline' OpenPandora overlay stuff that makes up the stock image (some custom libs, a logo and some image/task files etc.). My plan is to move meta-openpandora into a true hardware BSP layer so that you can just add this to give you full hardware support for the OpenPandora to any existing combination of OE layers (e.g. kernel, bootloader, netbase, formfactor, basefiles etc.). As part of this the rest of the 'not for mainline/cruft' stuff would need to find its way into a companion layer (say meta-openpandora-vendor or some such). Is this a good idea? It seems that way to me and would give a clear distinction on the layers. For example, add meta-openpandora to meta-angstrom to build mainline Angstrom for the OpenPandora. Add meta-openpandora-vendor to meta-openpandora and meta-angstrom to make a 'vendor customised' OpenPandora image etc. etc... Any mainline stuff that would need to be added (Xfce from oe.dev for example) would obviously get fed in as appropriate via oe-core/meta-oe and/or meta-angstrom (and maybe meta-ti) with only the vendor 'cruft' ever living in the meta-openpandora-vendor tree and all generic stuff finding its way upstream. I get the impression that some others may also be working in a similar way but I would not mind a little confirmation that it is a decent way of working before I sink time into it and if not what would be the preferred way to accomplish this (working under the assumption that there will always be a small amount of vendor 'cruft' living off to one side even if it just becomes some small logos and things like a GTK theme). PS: There are also customised versions of the Angstrom setup scripts on that GIThub site, once this settles my plan would be to fold any of that back into the main Angstrom setup scripts and just provide a customised layers.txt to support adding the one or more OpenPandora layers (Inc. the vendor one). Regards, John Willis -- > What is a grue? The grue is a sinister, lurking presence in the dark places of the earth. Its favourite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale. _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
