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

Ernest Van Hoecke <[email protected]> Fri, 29 May 2026 18:06:02 +0200
Newsgroups org.openembedded.lists.bitbake-devel
Message-ID <tgfbutopbavkq6ehs2g62lkfpw7guzyfpucg46lj2p2j534f2b@aaiam4e7b4xf>
On Fri, May 29, 2026 at 05:56:46PM +0200, Alexander Kanavin wrote:
> On Fri, 29 May 2026 at 16:52, Ernest Van Hoecke via
> lists.openembedded.org
> <[email protected]> wrote:
> > Allow a BitBake configuration to list source override files to apply by
> > default when that configuration is selected. This allows specifying
> > source-overrides files (such as fixed revisions) that live in a remote
> > registry, which is not possible with the CLI argument
> > '--source-overrides'.
> 
> I'm not sure I like the idea. One of the design goals was that a
> configuration file is self-contained, and adding references to other
> files greatly complicates the logic (e.g. I can't figure out from
> reading the changes if 'update' and 'status' operations will still
> work properly, probably they won't, as the tests don't check updates
> to the default overrides, or going from using default overrides to not
> using them), and decreases readability.
> 
> Is the issue that you'd like to avoid having multiple files for tagged
> releases, with largely same configuration content, and different
> source revisions? I'd like to understand the use case first.
> 
> Alex
> 

Hi Alex,

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.

Kind regards,
Ernest