Re: [OE-core] [PATCH 2/4] lib/recipeutils: add a function to determine recipes with shared include files

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2024-07-17 at 20:22 +0200, Alexander Kanavin via lists.openembedded.org wrote:
> From: Alexander Kanavin <alex@linutronix.de>
> 
> 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