Re: [bitbake-devel] [PATCH RFC] bitbake-setup: add source choices

On Tue, 16 Jun 2026 at 13:05, Ernest Van Hoecke via
lists.openembedded.org
<[email protected]> wrote:
> In this proposal, I instead added an optional "source-selection"
> property to the configurations node. This would behave as follows:
>   * If the selected config has no "source-selection": use top-level
>     "sources"
>   * If the selected config has "source-selection", but no top-level
>     "source-choices" is present: error out
>   * If the selected config has "source-selection" and "source-choices"
>     is present:
>     - When "source-selection" is a string or 1-element array, choice is
>       made automatically
>     - When "source-selection" is an array with multiple entries, user
>       has to make a choice out of the given options

Thanks for pushing this forward!

Keep in mind that I'd like to support 'folding' existing registry
configurations with this into just two files (oe, poky), so any
proposal should include a rework of them that showcases the feature
(e.g. add new json files, but don't touch existing ones).

Allowing both 'sources' and 'source-choices' complicates the logic and
understanding of it. The relation between 'sources' and
'source-choices' when both are present is not obvious. The use case of
choosing from all available options when there's no explicit
'source-selection' is not supported, it just falls back to 'sources'.

So I'm leaning towards making "sources" and "source-choices" mutually
exclusive, you can have one, or the other, but not both. This makes
the logic much simpler: if you have 'sources', then that is always
selected because there is nothing else. If you have 'source-choices',
then the user needs to select from available options (subject to
possible filters), unless there is only one choice, which is then
auto-selected. Making a choice works same way as for configurations:
either an identifier on the command line, or interactive selection.
Each choice should have its own expiration date, because each choice
can be a yocto release.

There's also the question of the order in which the user should be
making selections: what is more natural, sources first, configurations
second, or the opposite? Typically one selects a yocto release (or tip
of master) first, and a particular configuration in that release next,
but this RFC forces the opposite order. I think we should keep the
order.

To keep things manageable, I would suggest that this is split into
several commits, so the parts that are not controversial can be merged
quicker, and the parts that are can be refined and adjusted.
Specifically, can you first add the mutliple source choices support
that can be used with any configuration, and then add 'source-choices'
filter in a separate commit? So that how we do filters can be
discussed separately.

Thanks,
Alex