Yesterday I've spent some time migrating the layers I sometimes use. It's definitely not perfect, but it's useful as a starting point (I was even able to build an image with these changes).
I've sent my WIP changes for meta-oe, meta-python2, meta-security repositories to corresponding MLs. And here are draft PRs for projects maintained on github: https://github.com/advancedtelematic/meta-updater/pull/816 https://github.com/OSSystems/meta-browser/pull/530 https://github.com/shr-distribution/meta-smartphone/pull/137 https://github.com/webOS-ports/meta-webos-ports/pull/462 https://github.com/webOS-ports/meta-rpi-luneos/pull/8 https://github.com/webOS-ports/meta-pine64-luneos/pull/18 https://github.com/agherzan/meta-raspberrypi/pull/886 https://github.com/meta-rust/meta-rust/pull/357 https://github.com/shr-project/meta-webosose/pull/2 https://github.com/shr-project/meta-qt6/pull/1 https://github.com/meta-qt5/meta-qt5/pull/420 Regards, On Wed, Jul 28, 2021 at 5:44 PM Richard Purdie < [email protected]> wrote: > 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 > weeks? > > Cheers, > > Richard > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1296): https://lists.openembedded.org/g/openembedded-architecture/message/1296 Mute This Topic: https://lists.openembedded.org/mt/84508148/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
