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

On Mon, Jun 01, 2026 at 03:50:05PM +0200, Alexander Kanavin wrote:
> On Mon, 1 Jun 2026 at 14:43, Ernest Van Hoecke
> <[email protected]> wrote:
> > I arrived at this from a real use case. Admittedly, that might now be
> > semi-artifical if we don't want the other default-source-overrides
> > patch.
> >
> > My setup idea was to have all sources move, then use a fixed revisions
> > override to create a "release" setup at known pins, and then apply
> > another override on top of that one to create an "integration" setup for
> > CI where most sources are at known pins, but some repos are at latest.
> >
> > By overriding again, it prevents needing to maintain a "release" and
> > "integration" sources override files, that are mostly duplication of
> > each other.
> 
> But why can't 'release' be a full json config? If that leads to
> multiple duplicated configs for each release, then we should pursue
> the 'souces-one-of' idea to have multiple source sets in configs.
>

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.
 
> > You're right that this can easily be managed with other tools, the small
> > risk I see is that lots of custom solutions start growing around
> > bitbake-setup, but with your feedback on the other patch I also see less
> > value in this one.
> >
> > In short, the expectation here is that people use their own tooling to
> > manage the .conf.json and source overrides .json files? If so I'll send
> > a patch later to remove the multiple --source-overrides option from the
> > docs.
> 
> Overiddes are meant as something local and throw-away, and not
> something that is ever checked into a public git repo or otherwise
> shared. They're not self-describing for example, if you look at the
> content, there's no way to tell what is it for. Allowing multiple
> overrides that are overlaid on top of each other also makes it more
> difficult to tell what would be the final result, it's hard enough to
> figure how bitbake variables get their final values, and we don't need
> to repeat that :)
> 

That is a very compelling argument :) 

> So if a certain set of sources is reused between many builds, it
> should really be in a config. Bitbake-setup could help with that, e.g.
> 'take this override and add it to this config' command.
> 
> Alex
> 

Agreed and I've experimented with just using jq to overwrite the sources
node, I see this as the way forward. If I find a reason maybe I'll
integrate the behaviour straight  into bitbake-setup once we have an
idea on the multiple source sets/overrides concept. Thanks for your
thinking on this.                     
                                                                         
Ernest