On Fri, 2021-07-16 at 11:44 -0500, Mark Hatle wrote:

On 7/16/21 4:22 AM, Richard Purdie wrote:

On Thu, 2021-07-15 at 09:26 -0500, Mark Hatle wrote:

On 7/15/21 8:56 AM, Richard Purdie wrote:

Breaking things down a bit, one thing I keep running into with our current 
codebase and metadata is that overrides are not clear. In my previous email,
the example was:

do_configure_class-native

A human can usually spot "class-native" is and "configure" or 
"configure_class-native" is not. Bitbake's parser struggles. It has huge 
internal lists including variables like x86_64 where it has to track 
whether "64" in an override.

One way of fixing this is to be explicit about overrides and use a different 
separator. See an example patch below I made to the quilt recipe using ":" 
instead to see how it looks. Personally, I think this looks like an improvement.

There are two challenges:

a) The work of migration. Do we migrate piecemeal or with a flag day? I'm not
   sure piecemeal is even possible unfortunately.

b) Some of the packaging code (at the very least) needs rewriting as it accesses
   both RDEPENDS_${PN} and puts ${PN} in OVERRIDES and accesses RDEPENDS. I'm not
   sure what else may be assuming this works.

Ya, this is all over the packaging code. Should be trivial to move to treating
it as a variable (and not override). I can help with this if you want.

I've been pondering this a bit more and my preference is to move this to use 
overrides more explicitly.

The part of the code I worked on, the override was used as an optimization to avoid:

d.getVar("RDEPENDS_%s" % package) or d.getVar("RDEPENDS")

(and similar for all of the other variables that could be package specific.)

Overrides (at least to me) are system (or at least recipe) wide settings that
allow you to 'override' key things. The package items, based on that definitely
really aren't overrides -- they're package specific variables. (This is also
why I suggested RDEPENDS[package] might actually be a better syntax.)

Overrides are one of the key things which make OE function as an architecture and 
how a lot of the "magic" in our metadata happens. There is a hierarchy of overrides,
some are system wide some are local to specific functional areas but using them for
packaging is a natural fit.

As such, I'm very strongly in favour of explicitly exposing that rather than hiding
it.

FWIW the image class code also does something similar for IMAGE_CMD and image types.

I'm all for making override usage more clear to people. But in this ONE case, I
don't think these are really overrides -- and worse they could cause confusion
because they are ONLY overrides when packaging. So if you use the override
chunk in something that doesn't affect a package specific setting it won't do
anything. It also won't do anything on the functions (I think), as those are
run before the override is loaded.

Specific code I'm talking about BTW is:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package_rpm.bbclass

starting at line 287. (srcname is PN-src BTW)

then the loop starting at 328. Iterates over PACKAGES and sets the override one
at a time to the package name to get (conffiles, dirnames, summary/description,
pkgv, pkgr, pkge, license, section, description, rdepends, rrecommends,
rsuggests, rprovides, rreplaces, rconflicts, and I suspect a few others...)

Note, I could make the above changes pretty quickly and just submit this as an
implementation change in a few hours. I'd be happy to do that and look for
other 'in-place' usages of d.setVar("OVERRIDE"... to see if there are other
things like this.

As above, I'm very much of the opposite view, I think we want to promote this,
not remove it. Yes, you can emulate overrides with other forms of variable access
but that really isn't how the system was designed to be used.

Cheers,

Richard