What is the recommended method to patch a recipe?


nus1998 <nus1998@...>
 

Hi All,

I googled some topics on how to patch a recipe, most of them recommend to generate a corresponding <foo>.bbappend to apply the patch, I wonder if there is already a bbappend file, shall I modify the bbappend file directly, or create another layer to overwrite the bbappend file (and including the patchs in original bbappend file)?

Thanks in advance
Nus


Thomas Goodwin
 

As with a lot of things, I’m sure it all depends on the scope of the change.  Personally, if I ‘own’ the original bbappend, then I consider if it’s worth establishing an override or some other similar mechanism within that bbappend, depending on what I’m developing (an image feature or something machine-specific).  If it’s a one-off for a specific build that I can lump together with other changes, then I go with a new layer specific those changes.

One thing to keep in mind is that if you create your own layer with a bbappend ,then layer priority will impact which portions of your bbappend overwrite the others and the original recipe.  You can use bitbake -e package-name to get a view of how bitbake is overlaying all changes for it.

Cheers,

Thomas

On Apr 13, 2020, 4:20 AM -0400, nus1998 <nus1998@...>, wrote:
Hi All,

I googled some topics on how to patch a recipe, most of them recommend to generate a corresponding <foo>.bbappend to apply the patch, I wonder if there is already a bbappend file, shall I modify the bbappend file directly, or create another layer to overwrite the bbappend file (and including the patchs in original bbappend file)?

Thanks in advance
Nus


Nicolas Dechesne
 



On Mon, Apr 13, 2020 at 10:20 AM nus1998 <nus1998@...> wrote:
Hi All,

I googled some topics on how to patch a recipe, most of them recommend to generate a corresponding <foo>.bbappend to apply the patch, I wonder if there is already a bbappend file, shall I modify the bbappend file directly, or create another layer to overwrite the bbappend file (and including the patchs in original bbappend file)?

A good rule of thumb is to never modify a metadata that is not yours. That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or any other layer your are using).


Thanks in advance
Nus


Alexander Kanavin
 

On Mon, 13 Apr 2020 at 12:46, Nicolas Dechesne <nicolas.dechesne@...> wrote:
A good rule of thumb is to never modify a metadata that is not yours. That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or any other layer your are using).

I beg to differ! Bbappends are making it difficult to reason about what the recipe with all its appends is doing (because they destroy spatial locality and aren't easily visible), and I would actually discourage using them if the modification can go to the original recipe.

Is it fixing a problem? Is it adding a build option absent from the original recipe? Then please take the trouble to submit the change to the owners of the recipe.

Similarly, if a bbappend is re-setting the component version to something else (yes, people do that despite my best efforts to prohibit the practice), then a much cleaner approach is to actually make a fully copy of the recipe, or go and fix the original.

Alex


Nicolas Dechesne
 



On Mon, Apr 13, 2020 at 12:55 PM Alexander Kanavin <alex.kanavin@...> wrote:
On Mon, 13 Apr 2020 at 12:46, Nicolas Dechesne <nicolas.dechesne@...> wrote:
A good rule of thumb is to never modify a metadata that is not yours. That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or any other layer your are using).

I beg to differ! Bbappends are making it difficult to reason about what the recipe with all its appends is doing (because they destroy spatial locality and aren't easily visible), and I would actually discourage using them if the modification can go to the original recipe.

Ok.. you're right. Well at least my answer is not complete ;)


Is it fixing a problem? Is it adding a build option absent from the original recipe? Then please take the trouble to submit the change to the owners of the recipe.

This is correct. We should encourage everyone to report, and even better propose a fix, to the relevant layer, when the 'problem' is applicable. I didn't want to discourage that, for sure!
When developing against master, it's a no brainer. When developing against a stable branch (like probably many users), it's not as obvious. In that case I think trying to avoid 'touching' somebody else layer remains a good advice, since it makes upgrades and maintenance trickier.

 

Similarly, if a bbappend is re-setting the component version to something else (yes, people do that despite my best efforts to prohibit the practice), then a much cleaner approach is to actually make a fully copy of the recipe, or go and fix the original.

Recipes version upgrades (or downgrade) should be done in a dedicated layer owned by the 'developer', and in that case, I agree that bbappend should be prohibited, and the entire recipe should be copied.


Alex


Philip Balister
 

On 4/13/20 10:31 AM, Nicolas Dechesne wrote:
On Mon, Apr 13, 2020 at 12:55 PM Alexander Kanavin <alex.kanavin@...>
wrote:

On Mon, 13 Apr 2020 at 12:46, Nicolas Dechesne <
nicolas.dechesne@...> wrote:

A good rule of thumb is to never modify a metadata that is not yours.
That applies to everything:
* if you need to modify a bb file from a 3rd party library, create a
bbappend file in your layer
* if you need to modify a bbappend from a 3rd party, then create another
bbappend in your layer

And by 3rd party i mean any layer/tree which is not yours (OE-core, or
any other layer your are using).
I beg to differ! Bbappends are making it difficult to reason about what
the recipe with all its appends is doing (because they destroy spatial
locality and aren't easily visible), and I would actually discourage using
them if the modification can go to the original recipe.
Ok.. you're right. Well at least my answer is not complete ;)


Is it fixing a problem? Is it adding a build option absent from the
original recipe? Then please take the trouble to submit the change to the
owners of the recipe.
This is correct. We should encourage everyone to report, and even better
propose a fix, to the relevant layer, when the 'problem' is applicable. I
didn't want to discourage that, for sure!
When developing against master, it's a no brainer. When developing against
a stable branch (like probably many users), it's not as obvious. In that
case I think trying to avoid 'touching' somebody else layer remains a good
advice, since it makes upgrades and maintenance trickier.




Similarly, if a bbappend is re-setting the component version to something
else (yes, people do that despite my best efforts to prohibit the
practice), then a much cleaner approach is to actually make a fully copy of
the recipe, or go and fix the original.
I just ran across a bbappend that change configure options, but looking
at the original recipe, there is a PACKAGECONFIG option to do the same
thing. So they could have used that mechanism instram of the bbappend.

Philip

Recipes version upgrades (or downgrade) should be done in a dedicated layer
owned by the 'developer', and in that case, I agree that bbappend should be
prohibited, and the entire recipe should be copied.


Alex