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