mbox series

[RFC,v2,0/2] bitbake-setup: add source choices

Message ID 20260618-bb-setup-source-choices-integrated-tests-v2-0-66b3b438f073@toradex.com
Headers show
Series bitbake-setup: add source choices | expand

Message

Ernest Van Hoecke June 18, 2026, 6:04 p.m. UTC
A previous series raised the idea of defining multiple named source sets
in the top level configuration. [1]

Alex suggested selecting sources before BitBake configurations, making
sources and source-choices mutually exclusive, and discussing filters
separately.

This RFC implements the base mechanism:

  * Config files define exactly one of sources or source-choices.
  * Existing sources configurations keep their current behavior.
  * source-choices are selected before BitBake configurations.
  * Positional arguments use a source-first prefix grammar:

    bitbake-setup init <config> [source-choice] [bitbake-config] [fragments...]

  * A single unexpired source choice can be auto-selected.
  * Multiple source choices prompt, or fail in non-interactive mode.
  * The selected source choice is stored and replayed explicitly.
  * Source choices can have an expires field.

The prefix grammar means users cannot specify a BitBake configuration
positionally while leaving source choice interactive. They must either
specify the source choice first, or make selections interactively from
source-choice selection onward.

This patch series replaces the release-specific OE and Poky registry
files with consolidated examples to demonstrate how source choices can
combine the existing master, whinlatter and wrynose configurations.

The consolidated registry examples intentionally do not preserve the
exact setup-dir-name behavior of the existing release-specific files.
Today, setup-dir-name can substitute oe-fragments-one-of selections, but
it has no way to refer to the selected source choice. Possible follow-ups
include a built-in source-choice substitution variable or a different way
to model source/config combination metadata. For a substitution variable,
we have to prevent collision with a fragment choice.

This RFC intentionally leaves documentation out until the feature shape
is agreed.

Changes in v2:
  * Make sources and source-choices mutually exclusive.
  * Select source choices before BitBake configurations.
  * Store the selected source choice for non-interactive replay.
  * Add consolidated OE and Poky registry examples.

v1: https://lore.kernel.org/r/20260616-bb-setup-source-choices-integrated-tests-v1-1-a1e51bdeead5@toradex.com

[1] https://lore.kernel.org/bitbake-devel/CANNYZj9rKRS0CD-LGq=phvB_T1XS+SmR5Uti0p8tu49PtTm-QA@mail.gmail.com/

Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

---
Ernest Van Hoecke (2):
      bitbake-setup: add source choices
      default-registry: consolidate OE and Poky release configs

 bin/bitbake-setup                                  |  71 ++++++++-
 .../configurations/oe-nodistro-master.conf.json    |  47 ------
 .../oe-nodistro-whinlatter.conf.json               |  56 -------
 .../configurations/oe-nodistro-wrynose.conf.json   |  48 ------
 .../configurations/oe-nodistro.conf.json           | 117 +++++++++++++++
 .../configurations/poky-master.conf.json           |  73 ----------
 .../configurations/poky-whinlatter.conf.json       |  80 ----------
 .../configurations/poky-wrynose.conf.json          |  74 ----------
 default-registry/configurations/poky.conf.json     | 161 +++++++++++++++++++++
 setup-schema/bitbake-setup.schema.json             |  41 ++++++
 10 files changed, 387 insertions(+), 381 deletions(-)
---
base-commit: 733161c76bd2ac777555d3eac113ff54b4c63ae2
change-id: 20260616-bb-setup-source-choices-integrated-tests-5c2d3a31a95e

Best regards,

Comments

Alexander Kanavin June 19, 2026, 10:58 a.m. UTC | #1
On Thu, 18 Jun 2026 at 20:04, Ernest Van Hoecke
<ernestvanhoecke@gmail.com> wrote:
> The consolidated registry examples intentionally do not preserve the
> exact setup-dir-name behavior of the existing release-specific files.
> Today, setup-dir-name can substitute oe-fragments-one-of selections, but
> it has no way to refer to the selected source choice. Possible follow-ups
> include a built-in source-choice substitution variable or a different way
> to model source/config combination metadata. For a substitution variable,
> we have to prevent collision with a fragment choice.

Yes, there probably should be a 'special' variable for substituting
the selected source, and a check that there's no fragment selection
that has the name (in the unlikely case there's an accidental clash -
it's easy to address by tweaking the name of the fragment selection
block).

Alex