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