Re: Overrides conversion plan

Richard Purdie

On Sat, 2021-07-31 at 15:29 +0000, Peter Kjellerstedt wrote:
-----Original Message-----
From: openembedded-architecture@... <openembedded-
architecture@...> On Behalf Of Richard Purdie
Sent: den 30 juli 2021 15:40
To: openembedded-architecture <openembedded-
Subject: Re: [Openembedded-architecture] Overrides conversion plan

On Wed, 2021-07-28 at 16:43 +0100, Richard Purdie via wrote:

I have continued to work on this and I now think we're as ready as we'll
be with the core. I have:

* submitted a section for the migration guide documenting the conversion
* increased the minimum bitbake version for OE-Core
* bumped the local.conf version to require new versions of the config file
* added an error to bitbake if it sees "_append"|"_prepend"|"_remove" in
  variable names which would suggest an unconverted layer. If you use
  in function names in the datastore that was never a good idea and is no
  longer supported.
* merged compatibility changes back to bitbake 1.50, 1.48 and 1.46
* merged the conversion script to OE-Core
* merged submitted tweaks to the conversion script (thanks Martin!)
* made OE-Core honister only, no longer supporting hardknott
* updated converted layers to be honister compatible
* converted autobuilder-helper to use the new syntax
* ensured all of a-quick builds on the autobuilder
* submitted patches for meta-yocto, meta-gplv2, meta-mingw and bitbake

I plan to merge these various things on Monday (2nd August). After that
time, unconverted layers will no longer work with master.


[ I am on summer vacation so I just happened to see a tweet about this. ]

I am sorry to say, but I think you are going too fast. AFAICT, the support
for using : instead of _ in overrides is not yet in any Dunfell or Hardknott
release, only on the branches. I can't speak for others of course, but at
least we will not pick it up until it is included in an actual release.
There are releases of hardknott and dunfell currently in QA so this won't
make it in until the ones after that.

I understand the concern however I don't think it is reasonable to wait that
long. You do have the options of pulling in the changes earlier, or 
back porting them and if that isn't an option, it shouldn't be that long until
the next releases happen.

I am trying hard to find ways to allow things to operate over multiple releases
and I think we have come up with a good plan there for this change. This is not 
something we have ever planned or committed to supporting though. I think it
is in fact dangerous as it is effectively tying the project into never changing
anything, or if it does, planning changes in multiple years time which isn't in
my view reasonable. I worry that the bar to making any change like this is so
high as to put off anyone from ever doing it. The master branch is a development
branch at the end of the day.



Join to automatically receive all group messages.