Openembedded Devel Discussions
 help / color / mirror / Atom feed
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




  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