when is it appropriate to push recipe enhancements (eg., class-nativesdk) upstream?

when is it appropriate to push recipe enhancements (eg., class-nativesdk) upstream?

[Robert P. J. Day]

based on recipe from an existing (zeus-based) project, colleague asks
about a bbappend file, and whether it's appropriate that it be submitted
upstream as a patch -- this example involves "pciutils" recipe from
oe-core, but the question more generally covers any number of recipes.

this particular code base has the following pciutils_%.bbappend file:

=== start ===
PACKAGECONFIG_class-nativesdk = ""

DISABLE_STATIC_pn-nativesdk-pciutils = ""

# Need nativesdk-specific do_install due to ${sbindir} being set to usr/bin
do_install_class-nativesdk () {
         oe_runmake DESTDIR=${D} install install-lib

         oe_multilib_header pci/config.h
}

BBCLASSEXTEND += "nativesdk"
=== end ===

i'm looking at this for the first time and, sure, it appears to
extend the pciutils recipe for nativesdk. but if that's true, then
would it not make sense to submit that as a patch?

the current zeus "pciutils_3.6.2.bb" recipe doesn't extend the
recipe for nativesdk, so if this bbappend file actually correctly
does that, would it not make sense to contribute that enhancement
back?

in general, there appear to be numerous recipes in this code base
that do little more than extend the recipe for native and nativesdk
because the oe-core (or meta-oe) recipes don't do that.

am i thinking about this correctly? it seems that, if local bbappend
content fixes or enhances a recipe, it would make sense to push that
fix so as to not have to carry around the bbappend files.

thoughts? i'm not passing any judgment on the correctness of this
particular bbappend file, i'm more interested in the general
philosophy of pushing improvements to not have to keep carrying
them around in the local code base.

rday

Re: [yocto] when is it appropriate to push recipe enhancements (eg., class-nativesdk) upstream?

[Ross Burton]

For simple things like adding native/nativesdk then pushing them
upstream is easy and simple.  I'm trying to avoid commenting on that
specific bbappend...

Ross

On Wed, 5 Aug 2020 at 12:14, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> based on recipe from an existing (zeus-based) project, colleague asks
> about a bbappend file, and whether it's appropriate that it be submitted
> upstream as a patch -- this example involves "pciutils" recipe from
> oe-core, but the question more generally covers any number of recipes.
>
> this particular code base has the following pciutils_%.bbappend file:
>
> === start ===
> PACKAGECONFIG_class-nativesdk = ""
>
> DISABLE_STATIC_pn-nativesdk-pciutils = ""
>
> # Need nativesdk-specific do_install due to ${sbindir} being set to usr/bin
> do_install_class-nativesdk () {
>          oe_runmake DESTDIR=${D} install install-lib
>
>          oe_multilib_header pci/config.h
> }
>
> BBCLASSEXTEND += "nativesdk"
> === end ===
>
> i'm looking at this for the first time and, sure, it appears to
> extend the pciutils recipe for nativesdk. but if that's true, then
> would it not make sense to submit that as a patch?
>
> the current zeus "pciutils_3.6.2.bb" recipe doesn't extend the
> recipe for nativesdk, so if this bbappend file actually correctly
> does that, would it not make sense to contribute that enhancement
> back?
>
> in general, there appear to be numerous recipes in this code base
> that do little more than extend the recipe for native and nativesdk
> because the oe-core (or meta-oe) recipes don't do that.
>
> am i thinking about this correctly? it seems that, if local bbappend
> content fixes or enhances a recipe, it would make sense to push that
> fix so as to not have to carry around the bbappend files.
>
> thoughts? i'm not passing any judgment on the correctness of this
> particular bbappend file, i'm more interested in the general
> philosophy of pushing improvements to not have to keep carrying
> them around in the local code base.
>
> rday
>
>
> 

Re: [yocto] when is it appropriate to push recipe enhancements (eg., class-nativesdk) upstream?

[Khem Raj]

On Wed, Aug 5, 2020 at 4:14 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> based on recipe from an existing (zeus-based) project, colleague asks
> about a bbappend file, and whether it's appropriate that it be submitted
> upstream as a patch -- this example involves "pciutils" recipe from
> oe-core, but the question more generally covers any number of recipes.
>
> this particular code base has the following pciutils_%.bbappend file:
>
> === start ===
> PACKAGECONFIG_class-nativesdk = ""
>
> DISABLE_STATIC_pn-nativesdk-pciutils = ""
>
> # Need nativesdk-specific do_install due to ${sbindir} being set to usr/bin
> do_install_class-nativesdk () {
>          oe_runmake DESTDIR=${D} install install-lib
>
>          oe_multilib_header pci/config.h
> }
>
> BBCLASSEXTEND += "nativesdk"
> === end ===
>
> i'm looking at this for the first time and, sure, it appears to
> extend the pciutils recipe for nativesdk. but if that's true, then
> would it not make sense to submit that as a patch?
>
> the current zeus "pciutils_3.6.2.bb" recipe doesn't extend the
> recipe for nativesdk, so if this bbappend file actually correctly
> does that, would it not make sense to contribute that enhancement
> back?
>

yes, it would be good to send a patch to extend the recipe to upstream oe-core
I also see the bbappend is using a greedy wildcard, sometimes they can
be error prone when upgrading
to newer versions of oe-core, so usually I like to recommend that
create version specific bbappends so
it reminds you of this quirk when recipe is upgraded underneath.

> in general, there appear to be numerous recipes in this code base
> that do little more than extend the recipe for native and nativesdk
> because the oe-core (or meta-oe) recipes don't do that.
>
> am i thinking about this correctly? it seems that, if local bbappend
> content fixes or enhances a recipe, it would make sense to push that
> fix so as to not have to carry around the bbappend files.
>
> thoughts? i'm not passing any judgment on the correctness of this
> particular bbappend file, i'm more interested in the general
> philosophy of pushing improvements to not have to keep carrying
> them around in the local code base.
>
> rday
>
>
>