Re: [bitbake-devel] [PATCH 1/2] bitbake-setup: support multiple source override files

On Mon, 1 Jun 2026 at 21:21, Ernest Van Hoecke
<[email protected]> wrote:
> Agreed, I'm playing with this idea now. How would you feel about a
> top-level definition of:
>
>     "source-override-sets": {
>         "release": { "sources": { ... } },
>         "dev": { "sources": { ... } }
>     }
>
> That can then be selected by a config with
>
>     "source-override-set": "release"
>
> I don't really see the use case of having this be user selectable such
> as the "oe-template-one-of" property. Seems to me that it'd just create
> another axis of choice for the setup but at least for me, the sources
> would always be tied to a certain config. For example, my dev config
> also applies some other templates that differentiate it from the release
> config, so release+"dev sources" is not enough, and I'm not interested
> in creating a dev setup with release sources or vice versa.
>
> I'm struggling a bit with the semantics of this new approach tho. It
> makes me think that we really just want multiple sources nodes, not
> overrides.

I wouldn't call them 'override sets' as they're actually the starting
point, I'd go with something like 'source-choices'.

The use case for making them user selectable can be seen right here:
https://git.openembedded.org/bitbake/tree/default-registry/configurations

There's a lot of copy-paste in these configs, because each can hold
only one set of sources, and folding different yocto releases (plus
master) into a single config file would be great, so that actual build
configurations need to be written only once. I can imagine downstream
users could use it in a similar way: share configs between different
releases.

Adding restrictions on what config can be used with what set of
sources can be done as a followup, and doesn't need to be decided and
agreed up front. Until then you'd have to maintain that restriction
externally, by ensuring bitbake-setup is called with matching items:

$ bitbake-setup init my-mega-config-file dev-sources dev-config

I'm considering whether the source sets should hold optional allow
lists and deny lists of what configs they can be used with:

    "source-choices": {
         "release": { "sources": { ... }, "configs-allow":
["release"], "description": "...", "expires": "yyyymmdd" },
         "dev": { "sources": { ... }, "configs-allow": ["dev"],
"description": "..." }
     }

This feels more elegant and flexible. But again, it doesn't have to be
implemented up front. The best way to add new features is incremental
and iterative.

Alex