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

I've been quiet but have been thinking a lot about the syntax discussions. I believe we do need to simplify things, at least so the majority of recipes have simpler assignment syntax that is

Greetings, Instead of "includelist" and "excludelist", what about just "includes" and "excludes"? This terminology is already used in rsync's manual (for example), and it seems lighter and clear

<richard.purdie@...> wrote: +1 I find the whole issue almost unbelievable but hey... A.A.

I'd note that it does actually raise "SkipRecipe" on the recipes in question so SKIP may actually be more consistent and help with understanding in other code. Cheers, Richard

In the variables table: PNBLACKLIST, I'd prefer PNEXCLUDELIST, or PNBLOCKLIST. (I think exclude better captures what it does.) Confused, where it says current name is whitelist, suggested rename

Hello all, The Yocto Project TSC has created a wiki page to start making notes of offending names and possible replacements. At some point, this wiki page should include a plan on moving forward. 

Hello, after a few days I've discovered the fallouts of my chat with RP. Just to be precise the layer is meta-handheld and the patch uncovering the issue

On 06/17/2021 02:05 AM, Andre McCurdy wrote: I think the initramfs issue is just an example. For this particular issue, we can come up with several different ways to solve it.

I don't think users generally have a good grasp of the concept of "what has gone before". They expect = to override ?= and _myoverride to override = and if the ordering of those assignments can

Because _forcevariable isn't positional. It means "no matter what else appears in the metadata, either before or after this assignment, I want the variable to end up with this value". I don't think

lists.openembedded.org <pb=pbcl.net@...> wrote: I'm not sure I understand this. Why is using the _forcevariable override somehow worse than inventing a new assignment operator to

Em qua., 16 de jun. de 2021 às 02:08, Chen Qi <Qi.Chen@...> escreveu: I really like the === proposal. -- Otavio Salvador O.S.

Yes, that's a fair point. As you say, I kind of have the sense that our classes are drifting towards being more like classes in a "real" programming language, complete with an actual API, and

On 06/15/2021 06:29 PM, Richard Purdie wrote: I think so. 1) In the view of compatibility, it's acceptable. Before the change, we have: _remove >

That is a good summary, yes. It certainly could be a solution to the problem but I worry that having variables that users should touch and not touch and variables shadowing other variables is going

<mark.hatle@...> wrote: I skimmed some of the thread so may have missed a detail... but if the initramfs recipe wants to forcefully over-ride a value of IMAGE_FSTYPES set by a BSP,

There is more then once I thought it would be good to add a flag for some sort of variable type. Specific for this reason. "This variable is a MACHINE variable, this is a DISTRO variable, this is a

Thanks for the background, I understand the issue a bit better now. It seems fairly apparent that what's wrong here isn't fundamentally an issue with OVERRIDES, it's more that the semantic layering

I'm going to intentionally avoid using "image" as gets overloaded I think. This is because an initramfs can be more than one of: - The only filesystem container we create for a MACHINE - A filesystem