[yocto] release management

Joshua Watt jpewhacker at gmail.com
Tue Aug 15 06:15:52 PDT 2017


On Tue, 2017-08-15 at 09:25 +0200, Mike Looijmans wrote:
> On 14-08-17 21:10, Gunnar Andersson wrote:
> > 
> > Hey Russell
> > 
> > I don't claim to be an authority on best practices but I will share
> > some
> > thoughts.
> > 
> > On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:
> > > Hello.
> > > 
> > > As I learn more about yocto and more importantly gain practical
> > > experience
> > > with it I have started to think about my release structure.  Is
> > > there a
> > > “best practices” document or something like that that speaks to
> > > this?
> > > For example, how does everyone deal with “external” meta layer
> > > dependencies?  My software uses poky and meta-openembedded, of
> > > course.
> > 
> > We simply use a parent project [1] that includes git submodules,
> > one per
> > yocto layer.  I'm of the opinion that if git (only) can be used,
> > why
> > introduce other tools?   But it requires you to learn and master
> > that
> > feature.
> > 
> 
> We arrived at exactly the same setup. One parent repository that
> contains the 
> project-unique recipes, and submodules for the layers it needs.
> 
> It's a lot better than attempting to script things. For one thing,
> git will 
> tell you the state of the submodules.
> 
> If I rembemer correctly, Android builds use a tool to manage the
> layer 
> repositories. I didn't much like it though. And "yet another tool"...

It's called "repo" https://code.google.com/archive/p/git-repo/.

In my experience git submodules work fine if you follow the core
workflow of adding new submodules and updating them to newer versions.
The workflows for deleting, renaming, changed upstream repostiory, etc.
for submodules is IHMO pretty bad. Pretty much every time I've tried
that it has resulted in a borked local repository that I either had to
manually go into the .git directory and fix, or just start over with a
fresh clone (perhaps I'm just bad at it or newer versions of git are
better?). Not to say you shouldn't use them, just be aware of some of
the catches so you can match the tool to your expected workflow.

For my $0.02: We use git submodules to manage the multiple yocto trees
we are pulling in and also keep "parallel" layers for each with the
local changes we want to make in .bbappends, where possible (following
the strategy of no modifying the original). We do (particularly for
older versions of Yocto) make changes to the core since we have local
mirrors, but we follow a strict policy of getting changes upstreamed
first, and they trying to get upstream to backport to our version (if
it is still supported).

> 
> 
> Kind regards,
> 
> Mike Looijmans
> System Expert
> 
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijmans at topicproducts.com
> Website: www.topicproducts.com
> 
> Please consider the environment before printing this e-mail
> 
> 
> 




More information about the yocto mailing list