Re: [bitbake-devel] [PATCH 2/2] bitbake-setup: support default source overrides

On Fri, May 29, 2026 at 06:40:04PM +0200, Alexander Kanavin wrote:
> On Fri, 29 May 2026 at 18:06, Ernest Van Hoecke
> <[email protected]> wrote:
> 
> > Thanks for your feedback, I understand your concern and was not sure how
> > to go about it for that reason.
> >
> > Yes, that's exactly the issue I'm facing. We would like to have a "dev"
> > and "release" setup. My current idea was to have the "dev" setup be the
> > default, with all revisions pointing to master/tip of the branch and use
> > source-overrides to create a "release" without relying on users to pass
> > it correctly.
> >
> > If users have to pass it on the CLI, it also creates an awkward
> > bootstrapping where they first have to check out our registry locally
> > before setting up the release build.
> >
> > And if revisions are tightly specified in the main conf.json, it's also
> > less straight forward to update it with the current fixed-revisions
> > system.
> 
> The overrides system was added for a different use case. We wanted to
> support CI systems which need to set up a build from something like a
> pull request, where one of the layers needs to come from a developer's
> branch, but everything else should remain standard. Another use case,
> added a bit later, was to write out fixed revisions override, so that
> a build that was set up from a floating revision config, could be
> reproduced exactly with specific revisions that were resolved at that
> point.

Thanks for the background info. I really liked the idea of using these
fixed revisions to then generate a "release", but maybe I've approached
the design problem from the wrong side. I could switch things around and
have fixed hashes in the main configuration, and have CI update those to
keep everything contained in one file, that can certainly be cleaner.

The drawback to me is that this "update"/"release" action moves outside
of bitbake-setup, but now that I think about it more, I can see how
separating that responsibility might be beneficial and indeed it should
be an easy Python/jq/.. job.
 
> I agree that supporting multiple sets of sources would be useful,
> perhaps you could look into adding a "sources-overrides" section into
> the json, which would contain multiple sets of overrides (e.g. 'dev',
> 'release', 'oldrelease'), and then the UI would allow selecting one
> interactively or through command line? Unfortunately 'sources' itself
> can't be extended like that.
> 
> Alex
> 

That's an interesting idea to go along with the above. We could keep
pinned "release" revisions, and then have "dev" move them back to a
branch tip. Not entirely sure it's worth the implementation effort since
it's less of a problem to have to remember passing overrides for a dev
setup than it is for a release, but I'd certainly prefer it to be
specified in the .conf.json instead of the CLI.

Thanks for your input, will have a think on our next steps. Probably
I'll have our tooling fill in the fixed revisions into the main
.conf.json.

Kind regards,
Ernest