From: Graeme Gregory <dp@xora.org.uk>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] turning conf/machine into a set of bblayers
Date: Thu, 21 Oct 2010 11:04:59 +0100 [thread overview]
Message-ID: <4CC0104B.4070108@xora.org.uk> (raw)
In-Reply-To: <i9p2uf$f40$1@dough.gmane.org>
On 21/10/2010 10:59, Koen Kooi wrote:
> On 21-10-10 11:52, Graeme Gregory wrote:
> > On 21/10/2010 10:33, Koen Kooi wrote:
> >> Hi,
> >>
> >> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
> >> nice topic for OEDEM to see if we discuss switching to a poky BSP
> model.
> >> It would boil down to:
> >>
> >> 1 base bblayer with shared files:
> >> * conf/machine/include
> >> * recipes/linux/*.inc
> >>
> >> 1 bblayer per machine or SOC_FAMILY containing:
> >> * machine.conf
> >> * first and second stage bootloaders
> >> * kernel
> >>
> >> So, what are peoples thoughts on this? I haven't thought this through
> >> myself, so feel free to point out any show stoppers.
> >> I do not want this to turn into a "splitting the metadata" discussion,
> >> while I'm all for that, it really is a seperate effort and discussion.
> >> But any bblayer style split would benefit from OE being a collection of
> >> git submodules instead of a monolithic tree[1].
> >>
> >> Regards,
> >>
> >> Koen
> >>
> >> [1] Provided git submodules stop sucking so hard in future git versions
> > This is something I have advocated before but never formally presented a
> > RFC to OEDEM.
>
> > With this model it quickly becomes clear which machines have support.
>
> > The only problem comes with BLAH_machine type overides. Are they done as
> > amend.inc (or whatever the current method is) in overlay or are they
> > allowed into main repo. I think amend.inc in this case is probably the
> > way to go.
>
> The downside of amend.inc is the de-sync when the recipe gets updated,
> but not the overlay. You run the risk of using a version without the
> overrides that way.
> Maybe some fancy scripts, (pre-)commit hooks or just old fanishioned
> review on the ml could solve those type of issues.
>
> How do file overrides like
> recipes/netbase/netbase/beagleboard/interfaces get handled in a
> bblayer/amend.inc world?
>
Such a pity git doesnt have increasing rev numbers, a cool adition would
be a flag in layer that showed the last rev of core it was tested with.
Layer was tested with core 1 but core is now 999 would give an
indication on drift between layers and core.
Graeme
next prev parent reply other threads:[~2010-10-21 10:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 9:33 [RFC] turning conf/machine into a set of bblayers Koen Kooi
2010-10-21 9:52 ` Graeme Gregory
2010-10-21 9:59 ` Koen Kooi
2010-10-21 10:04 ` Graeme Gregory [this message]
2010-10-21 10:17 ` Frans Meulenbroeks
2010-10-21 10:20 ` Frans Meulenbroeks
2010-10-21 10:38 ` Richard Purdie
2010-10-21 12:01 ` Frans Meulenbroeks
2010-10-21 13:46 ` Maupin, Chase
2010-10-21 14:21 ` Chris Larson
2010-10-21 16:11 ` Denys Dmytriyenko
2010-11-01 21:04 ` Tom Rini
2010-10-21 10:48 ` Richard Purdie
2010-10-21 11:22 ` Graeme Gregory
2010-10-21 14:21 ` Chris Larson
2010-10-21 10:36 ` Richard Purdie
2010-11-02 7:02 ` Frans Meulenbroeks
2010-11-02 20:46 ` Koen Kooi
2010-11-02 21:14 ` Eric Bénard
2010-11-02 21:19 ` Koen Kooi
2010-11-02 21:21 ` Tom Rini
2010-11-03 8:15 ` Frans Meulenbroeks
2010-11-03 14:59 ` Tom Rini
2010-11-03 18:59 ` Frans Meulenbroeks
2010-11-03 20:17 ` Tom Rini
2010-11-03 20:44 ` Khem Raj
2010-11-03 21:06 ` Frans Meulenbroeks
2010-11-03 22:13 ` Khem Raj
2010-11-04 7:48 ` Koen Kooi
2010-11-02 21:57 ` Khem Raj
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=4CC0104B.4070108@xora.org.uk \
--to=dp@xora.org.uk \
--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