All, Recently several Yocto Project members have expressed interest in being able to upgrade the Linux kernel in Dunfell LTS release from 5.4 to 5.10. Both of those Linux kernel versions are

Hi All, I now have an actual proposed plan for changing override syntax which I hope will mitigate the issues raised in the previous discussion as far a is possible whilst still letting the project

Branch updated, it now lets a core-image-sato build successfully. Cheers, Richard

The view I've also had and used to explain to others. There are two scopes of variables in OE. global and recipe specific. Adding an override anywhere else, really adds additional (hidden) scopes

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

(trimmed to add a minor comment) In this case ${PN} is just a name. It's because PACKAGES contains ${PN} by default. Really it's RDEPENDS_<package>. Which is distinctly different

Just to update, I have an experiment: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/overrides-convert This contains a conversion script which can convert poky to use ":"  instead

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

I'm not sure it is going to be feasible to take two years to make this kind of transition. I've been looking for alternatives and one possibility may be semi-automated translation. By that, I mean

Hi, I am getting error in do_image_rdk function while building the core-minimal-image for the rdk code. Please let me know how can i debug the error and where to see the full error log that can help

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,