Well, I am not asking we support both forever, but that we offer a proper transition period. For most key (and public) layers, it might be an option to switch 'quickly' enough, but for developers

I have to admit I'm leaning the other way, make this explicit and hope that it actually helps users understand overrides a little better by making it clear. If we support both forms, firstly, few of

I agree. I understand that this change would be needed to improve the metadata we currently have, but I would like to stress that such big change in syntax would be major PIA for some use

This is the dilemma. We hear a lot about usability and the syntax being confusing and hard to use/understand. If we try and improve that, we are going to have to break compatibility at some

I've been pondering this a bit more and my preference is to move this to use  overrides more explicitly. What I did realise is that d.getVar("RDEPENDS:${PN}") can actually split out the override

hey! Ouch.. I never realized that! I like Mark's suggestion to convert that to variables. RDEPENDS is typically used in users' layers, so that way they wouldn't be impacted by an override syntax

The idea is interesting, but it would certainly break layers out there that only provide a single master branch and claim compatibility with several past releases, including dunfell, or even older.

Hello Richard, Em qui., 15 de jul. de 2021 às 10:56, Richard Purdie <richard.purdie@...> escreveu: If we don't do as a flag day we cannot drop old code from bitbake, so my vote goes

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. (It can of course also be moved to overrides,

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