From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Regarding layers and their versioning.
Date: Mon, 21 Oct 2013 13:09:46 +0200 [thread overview]
Message-ID: <20131021110946.GD3709@jama> (raw)
In-Reply-To: <544da34b-acbf-44ca-8f84-fd993db893f4@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]
On Mon, Oct 21, 2013 at 09:29:27AM +0100, Anders Darander wrote:
>
>
> "Søren Holm" <sgh@sgh.dk> wrote:
> >Hello
> >
> >What is the best way to manage a private repo with recipes as well as
> >meta-oe,
> >meta-core and meta-angstrom.
>
> >Currently I have a private repo that has the layers attached as
> >submodules. Is
> >that a crazy setup or what?
>
> We're doing the same internally at ChargeStorm. One benefit is that we're having our "master" repo keeping track of all the layers that we're using and which revision of those layers.
>
> Other people / projects just use a shell script checking out the desired layers. Some people combines layers into one huge repo (though I'd personally not recommend that approach). (That'd be similar to how Poky is being managed).
>
> Yet other people / projects use repo.
>
> It's up to what you're comfortable with in the end.
I was using Makefile to checkout correct set of layers with correct
revisions for SHR before and then changed it to use layerman script
very similar to script used in angstrom-setup-scripts, because
layers.txt is more "declarative" and easier to update than what I had
in Makefile.
For webos-ports project I use the same.
For webos we recently switched from repo with submodules to repository
with similar script (mcf - this time in python). Mostly because repos
with submodules don't work well when replicating from gerrit to github.
I think that biggest advantage of solution with some script, is that
layers are still standalone checkouts, which developers can use as any
other project (easier to submit patches upstream etc).
And the script
can be more clever than git pull --rebase in repo with submodules, e.g.
for jenkins builds I want to automatically update build configuration in
non-interactive way (because jenkins shouldn't ever keep some local
changes), but for local build I want to preserve developer's local.conf
changes and e.g. extra layers added in bblayers.conf etc.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
prev parent reply other threads:[~2013-10-21 11:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-20 21:20 Regarding layers and their versioning Søren Holm
2013-10-21 1:16 ` Philip Balister
2013-10-21 21:09 ` Søren Holm
2013-10-21 8:29 ` Anders Darander
2013-10-21 9:01 ` Paul Eggleton
2013-10-21 14:17 ` Otavio Salvador
2013-10-21 9:05 ` Burton, Ross
2013-10-21 11:09 ` Martin Jansa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131021110946.GD3709@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox