On Fri, 2024-06-21 at 12:34 +0200, Alexander Kanavin via lists.openembedded.org wrote: > From: Alexander Kanavin <[email protected]> > > This is modeled on RECIPE_UPGRADE_EXTRA_TASKS with the difference > being that the tasks run in 'devtool finish', and only when > finishing an upgrade operation. This allows recipes to define > custom operations, such as renaming additional supplementary > recipes (such as *-initial, *-native etc), or any other custom > handling that devtool cannot know about. > > The idea is to teach glib, cmake, mesa, systemd, libva, rt-tests, > go, rust, etc etc about upgrading themselves properly with this, > improving success rates in AUH.
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. 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? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#201114): https://lists.openembedded.org/g/openembedded-core/message/201114 Mute This Topic: https://lists.openembedded.org/mt/106796297/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
