Hi Folks,
Below is a mail I sent to the Angstrom distribution list to seek some feedback on my thinking regarding oe-core/meta-oe/meta-angstrom etc. and how OpenPandora (or rather me in this context) can better work with upstream.
The feedback I got from that has been positive to working this way so I wanted to also gain some feedback from the OP guys who are not as close to OE/Angstrom. My plan is to follow this approach unless anyone has some major issues.
John
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.
Replying to myself,
Below is a mail I sent to the Angstrom distribution list to seek some feedback on my thinking regarding oe-core/meta-oe/meta-angstrom etc. and how OpenPandora (or rather me in this context) can better work with upstream.
The feedback I got from that has been positive to working this way so I wanted to also gain some feedback from the OP guys who are not as close to OE/Angstrom. My plan is to follow this approach unless anyone has some major issues.
As I only got positive feedback on IRC and none on the mailing list I have gone ahead and started to do the split.
I have pushed the results of a quick carve-up to https://github.com/openpandora and I'll start to redo this as time goes on.
Anyone using the https://github.com/openpandora/openpandora-oe-environment setup scripts will need to
'rm build/conf/bblayer.conf' and 'git pull' the latest scripts before running './openpandora-setup.sh config' again.
Now this is done I welcome pull requests and patches ;).
I have also added a 'recipes-user' directory to meta-openpandora-vendor that will not be parsed by GIT for temp storage of recipes that are being worked on locally (an idea from aTc).
This should mean you can create in tree and move into the correct dir when you want to get it committed if you're mildly allergic to working in GIT full time ;).
Thanks,
John