All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: Best practise using .bbappend
Date: Fri, 10 Aug 2012 12:06:28 +0100	[thread overview]
Message-ID: <1717286.mDh904HIi2@helios> (raw)
In-Reply-To: <5024E843.2050709@dynamicdevices.co.uk>

Hi Alex,

On Friday 10 August 2012 11:53:55 Alex J Lennon wrote:
> I'm trying to create a layer, overriding certain defaults with use of
> .bbappends.
> 
> e.g. Changing a Grub configuration with a
> meta-foo/recipes-bsp/grub/grub_1.99.bbappend
> 
> I'm wondering what happens when somebody updates the grub recipe in meta
> to a new version, e.g. 2.00 and I then do a git pull?
> 
> As I understand it the environment will automatically pick up the new
> recipe, and presumably my .bbappend to 1.99 will no longer be pulled in?

That's correct. We assume that the contents is often going to be version-
specific and therefore a bbappend needs to be created for each version. There 
have been discussions about adding wildcarding for bbappends, but so far I can 
only assume it hasn't been a serious enough problem for people - at least 
responses to the suggestion have been fairly muted.
 
> Should I be setting a PREFERRED_VERSION_bar somewhere, say in the conf
> for my new layer, on any recipe that I add a .bbppends to, or what's best
> practise for dealing with this?

Setting a PREFERRED_VERSION_ for each bbappended recipe is a reasonable 
approach assuming this is a layer intended to apply some policy (i.e. a distro 
layer).

In practice this is unlikely to come up too often - in OE-Core we usually 
delete the old recipe when upgrading to a new version, and thus if you have a 
bbappend for the old version in your layer you will get an error after parsing 
indicating the bbappend had no matching recipe.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



  reply	other threads:[~2012-08-10 11:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10 10:53 Best practise using .bbappend Alex J Lennon
2012-08-10 11:06 ` Paul Eggleton [this message]
2012-08-10 11:11   ` Paul Eggleton
2012-08-10 11:13   ` Alex J Lennon

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=1717286.mDh904HIi2@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=ajlennon@dynamicdevices.co.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.