Overrides conversion plan

Richard Purdie

Hi All,

I've spent quite a bit of time seeing how to progress things. I now
have a script which can convert layers and seems to have reasonable success
on OE-Core, bitbake, yocto-docs, meta-yocto, meta-gplv2 and meta-mingw. I've
proposed this for OE-Core along with an example conversion patch for OE-Core.

The current patch status is I have conversions (including to bitbake's core)
in master-next branches. This nearly has q-quick builds passing on the 
autobuilder, there are a handful of oe-selftest cases which don't pass yet.

Things do get a little more complex than I'd hoped. We use OVERRIDES
in a number of interesting places, including within multilib configurations
for the tune-XXX variable suffixes. I did try making the code do "fallback"
variable lookups instead of expansion for tune- but I quickly gave up due
to the nesting. My view is that they are being used as overrides and we should 
therefore recognise them as such. Over time I think the tune code can be
improved to take explicit advantage of that.

As such, I'm proposing we make the package variables and tune variables
explicit overrides and the conversion scripts and patches above assume this.

I think the challenge is going to be the flag day issue for master branches.
For example, there is code in devtool and other places which knows about the
override character. If we allow mixing the different syntax for master then
those tools need to complicate things by referencing both characters. To try
and preserve what is left of my sanity, I'm starting to think we just require
layers to migrate to the new syntax to continue to work with master. The good
news is that those converted layers should work with dunfell and older releases
where the layer already does that with the backported bitbake syntax update.

If we accept that we need to have a flag day for master use, the question is 
when. We could pick some data well in the future or even post 3.4 however I'm
not sure this buys much and we probably may as well get on and do it.

Given these things, I therefore propose that we should start these changes 
and require it for master, probably relatively quickly within a couple of 



Join openembedded-architecture@lists.openembedded.org to automatically receive all group messages.