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

On Tue, Jun 02, 2026 at 10:03:50AM +0200, Alexander Kanavin wrote:
> 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.
> 

That makes sense to me, in this case I'd add "source-choices" that
contain multiple "sources" nodes as you proposed. I'd like to start with
just that and the ability for a (leaf) config to select that with a
property "source-choice" so it does not have to be specified by the
user. That would already solve my use case, and also allow for folding
all these OE distros into one.

I can see how you might prefer the choice so you do not even need to 
specify multiple leaf configs, but then indeed we might (later) want
allow lists. I'll send an RFC or PATCH for this and we can see how it
feels.

> 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
>