Re: Should we change variable override formatting?

Richard Purdie

On Thu, 2021-07-15 at 23:48 -0400, Denys Dmytriyenko wrote:
On Thu, Jul 15, 2021 at 02:56:38PM +0100, 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:


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.

This change does buy us cleaner looking metadata and ultimately, a faster
and cleaner internal bitbake that at least would use less memory. It could set
the stage to allow the defval idea I mentioned in a previous mail to happen.

It is a huge change and would need a lot of work to make it happen. Is it worth 
doing? Not sure. I'm putting it out there for discussion.

It is also going to be tempting that "if we're breaking things, lets break lots".
I want to be mindful that tempting as that may be, if users can't convert clearly,
it will be worlds of pain. The benefit of this change is that at least in the
general case, the transition should be clear. Taking steps rather than changing the
world may therefore be a better idea...
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. Few come to mind - meta-browser,
meta-linux-mainline, meta-etherium, etc.
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 point/level.

We've not done it for a while but I'm not sure that is a good thing and we perhaps
do need to try and improve some things.

One possibility is that if we patched older bitbake's to substitute ":" for "_" in
variables coming into the data store, it might be able to handle metadata using 
the new delimiter to some level. I'm not entirely sure you could cover every possible
situation, it might work.

There would still end up being a flag day where beyond which we couldn't progress
without relying upon the new syntax. I'm a little reluctant to look too hard at that
as writing metadata to work with datastores with two different behaviours doesn't
sound like a great idea from a testing perspective and ultimately may hurt users more
that it would help.



Join to automatically receive all group messages.