On Wed, 2024-07-17 at 20:22 +0200, Alexander Kanavin via lists.openembedded.org wrote: > From: Alexander Kanavin <[email protected]> > > This functionality is needed for 'lockstep version upgrades' where several > recipes need to be upgraded at the same time to produce a buildable > outcome. > > The function itself obtains BBINCLUDED for each recipe and then massages > the data until it takes the form of a list of sets: > > [{'cmake','cmake-native'}, > {'qemu','qemu-native','qemu-system-native'}, > ... ] > > There's also a selftest that checks for the above. > > Unfortunately this won't detect mutually exclusive recipes like mesa and > mesa-gl > as they're chosen with PREFERRED_PROVIDER and can't be enabled in the same > build > at the same time. ('devtool upgrade' will also accept just one of them but > not the other)
This is partly why I was suggesting the internal list of files that bitbake has instead of BBINCLUDED, even if it comes from the same data. Even if a recipe is skipped (as conflicting providers are), I think the cache entry in bitbake is still needed to know if/when to reparse the recipe. Your patch is good and I'm happy to merge as is, I just wanted to mention that it might be possible to catch the mesa issue. The challenge is that even if it were identifiable, the code still probably can't know how to actually enable it for the upgrade/testing :(. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202315): https://lists.openembedded.org/g/openembedded-core/message/202315 Mute This Topic: https://lists.openembedded.org/mt/107403314/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
