On Tue, 2024-06-25 at 11:19 +0200, Alexander Kanavin wrote: > On Mon, 24 Jun 2024 at 22:33, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > Whilst I understand the desire, I'm not sure this lives up to way > > devtool works. > > > > By that I mean that devtool upgrade usually does testing of the result > > but with what you implement here, the second recipe is never actually > > tested so things could easily break after devtool finish and you > > wouldn't know without further testing. > > Yes. Supplementary .bb renaming only works if those additional recipes > do not add licensing statements, or custom patches (and AUH also won't > test-build them separately). It was something of a low hanging fruit I > wanted to try, as for things like mesa, qemu, cmake and others in the > patchset I sent this does turn reliably failing AUH updates into > working ones (as long as only the renaming is needed). > > > Thinking about this a bit more, we should be able to ask bitbake which > > other recipes "share" files since I think the list of included files is > > actually cached by bitbake. Yes, we may need API but in theory this > > means devtool can know which other recipes it needs to upgrade at the > > same time, and when doing so, run them through the same process as > > normal upgrades. > > > > So yes, it will be a bit more work but the end result should be more > > generic and scalable? > > I would first try to simply list the additional recipes directly in > the main one: > RECIPE_UPGRADE_ADDITIONAL = "qemu-native qemu-system-native" > and see if devtool can be easily made to iterate over them: > > devtool upgrade qemu > - internally performs upgrade qemu-native qemu-system-native > > devtool finish qemu > - does the same for finish operation. > > And since these share includes and patches and other items in SRC_URI, > we need to ensure they don't step on each other. Although there will > be multiple overwriting in 'devtool finish' which is okay as long as > one updated thing is overwritten with the same updated thing.
I don't think we even need to list the recipes like this. When devtool upgrade runs, we get a list of files which change. We can then query bitbake with that list of changed files and ask "which recipes also depend on these?". Based upon that list we can then know what else might need to change (e.g. if any of those recipe names have the same PV in) and also which recipe targets also need to be tested as part of the upgrade. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#201129): https://lists.openembedded.org/g/openembedded-core/message/201129 Mute This Topic: https://lists.openembedded.org/mt/106796297/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
