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

Alexander Kanavin <[email protected]> Mon, 1 Jun 2026 15:50:05 +0200
Newsgroups org.openembedded.lists.bitbake-devel,org.yoctoproject.lists.docs
Message-ID <CANNYZj-ajQ_2LJnTHMvC82JjtNxLRMPKEJO1ez_Paj6vb9NBdA@mail.gmail.com>
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.

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

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