All of lore.kernel.org
 help / color / mirror / Atom feed
* Best practise using .bbappend
@ 2012-08-10 10:53 Alex J Lennon
  2012-08-10 11:06 ` Paul Eggleton
  0 siblings, 1 reply; 4+ messages in thread
From: Alex J Lennon @ 2012-08-10 10:53 UTC (permalink / raw)
  To: openembedded-devel

Hi,

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?

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?

Thanks,

Alex




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Best practise using .bbappend
  2012-08-10 10:53 Best practise using .bbappend Alex J Lennon
@ 2012-08-10 11:06 ` Paul Eggleton
  2012-08-10 11:11   ` Paul Eggleton
  2012-08-10 11:13   ` Alex J Lennon
  0 siblings, 2 replies; 4+ messages in thread
From: Paul Eggleton @ 2012-08-10 11:06 UTC (permalink / raw)
  To: Alex J Lennon; +Cc: openembedded-devel

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Best practise using .bbappend
  2012-08-10 11:06 ` Paul Eggleton
@ 2012-08-10 11:11   ` Paul Eggleton
  2012-08-10 11:13   ` Alex J Lennon
  1 sibling, 0 replies; 4+ messages in thread
From: Paul Eggleton @ 2012-08-10 11:11 UTC (permalink / raw)
  To: Alex J Lennon; +Cc: openembedded-devel

On Friday 10 August 2012 12:06:28 Paul Eggleton wrote:
> > 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.

I forgot to mention, "bitbake-layers show-appends" will warn if there is a 
bbappend for one version of a particular PN but none for the current preferred 
version; thus it can be used to catch where this situation has occurred, the 
old recipe was not deleted and no PREFERRED_VERSION_ has been set.

In general bitbake-layers is quite a useful utility for querying layer 
configuration and interaction.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Best practise using .bbappend
  2012-08-10 11:06 ` Paul Eggleton
  2012-08-10 11:11   ` Paul Eggleton
@ 2012-08-10 11:13   ` Alex J Lennon
  1 sibling, 0 replies; 4+ messages in thread
From: Alex J Lennon @ 2012-08-10 11:13 UTC (permalink / raw)
  To: Paul Eggleton; +Cc: openembedded-devel

Hi Paul,

 >approach assuming this is a layer intended to apply some policy (i.e. 
a distro layer).

Good to know. I'm currently working with most of this in local.conf but
my plan is to migrate it to a distro configuration when I've figured out 
what I'm
doing, yes.

 >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.

Ah very good. So if I update from the git repo and a recipe I've 
extended has changed
I would get a build error rather than it silently dropping my changes. 
Good :)

Many thanks,

Alex




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-08-10 11:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-10 10:53 Best practise using .bbappend Alex J Lennon
2012-08-10 11:06 ` Paul Eggleton
2012-08-10 11:11   ` Paul Eggleton
2012-08-10 11:13   ` Alex J Lennon

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.