On Wed, Jan 14, 2026 at 12:19 PM Antonin Godard via
lists.openembedded.org
<[email protected]> wrote:
>
> Hi,
>
> On Wed Jan 14, 2026 at 1:02 AM CET, Otavio Salvador via
> lists.openembedded.org wrote:
> [...]
> > 1. Generic Configuration → BitBake Setup Template
> >
> > The term "Generic Configuration" does not immediately convey that this is a
> > reusable template file used as input to create a build environment. The
> > word "generic" can be interpreted as "basic" or "non-specialized" rather
> > than "reusable template."
> >
> > We suggest *BitBake Setup Template* as an alternative. This clearly
> > communicates that the .conf.json file serves as a template for creating
> > setups.
> > 2. Specific Configuration → BitBake Setup Instance
> >
> > Similarly, "Specific Configuration" does not clearly indicate that this is
> > the *result* of applying a template with user choices. The relationship
> > between "Generic" and "Specific" is not immediately obvious.
> >
> > We suggest *BitBake Setup Instance* as an alternative. The "Template →
> > Instance" pattern is widely understood by developers and immediately
> > conveys the relationship: a template is used to create an instance.
>
> I like the Template/Instance suggestion, but I'm not sure about removing the
> word "configuration" out of these terms. We are speaking about the
> _configuration_ of a Setup after all, and "BitBake Setup Instance" could be
> misinterpreted as a running bitbake-setup execution.
>
> So maybe:
>
> Bitbake Setup Configuration Template
> Bitbake Setup Configuration Instance
>
> or simply:
>
> Configuration Template
> Configuration Instance
>
> Would be enough. Having "BitBake Setup" prefixing every occurrence of this
> term
> is going to be too much otherwise?
>
> What do you think?
I personally don't like the idea of yet another configuration term.
But my main goal is avoid "generic/specific" so what was decided is ok
for me.
>
> > 3. Nested "configurations" → Variant
> >
> > Within a BitBake Setup Template, there are nested "configurations" (e.g.,
> > poky, poky-with-sstate) that represent predefined bundles of fragments and
> > settings. Using "configuration" here creates confusion since the term is
> > already heavily overloaded in the Yocto ecosystem.
> >
> > We suggest *Variant* as an alternative. This conveys that these are
> > different flavors or variations of the same base template, similar to how
> > distributions have variants or flavors.
>
> That sounds good to me, but would you also define a Variant as its own term
> (in
> the glossary)?
It all started in my mind when I decided to list all the elements of a
`.conf.json` and realized one of the pieces had no name. Then I
realized it could be called "bitbake configuration" if we look in the
`bitbake-setup init` output.
So yes, I think a new entry in the glossary would be helpful.
And I think a section with the what are the 4 elements of a
`.conf.json` is also missing (we currently have kind of it, but the
name "variant" is not clear enough for me)
And I don't understand why the "sources" element is shown as optional
as if you try to use a `.conf.json` with no source it does not fail,
but it produces nothing? (nothing I could find at least)
>
> [...]
> > 2. Allow Empty Variants in Templates
> >
> > Currently, bitbake-setup init requires the user to select a variant when
> > one is defined in the template. There is no option to skip this selection.
>
> I believe this is already achievable with the --skip-selection option?
This is the very first time my human eyes see "--skip-selection", I'm
sorry I completely missed it from the `--help`output
from the `bitbake-setup init --help` output
```
--skip-selection SKIP_SELECTION
Do not select and set an option/fragment from
available choices; the resulting bitbake configuration may be
incomplete.
```
It makes me think that we want to always provide the list of variants,
but sometimes we want to avoid choosing. But I only copied the output
to highlight that the variant term is needed (in my opinion), as once
you read you know what we are not selecting.
On my local tests, if I create a `.conf.json` without the variants
element, I face an error message.
>
> > Allowing templates without variants (or making variant selection optional)
> > would reduce the number of questions during setup, making the process
> > faster and more approachable for newcomers.
>
> Instead of no variants, maybe we just want to instruct the user to run:
>
> bitbake-setup init --non-interactive choice1 choice2 ...
>
> Another idea would be to make it possible to define default choices
> in an existing template? The documentation would then instruct the user to
> simply execute:
>
> bitbake-setup init --non-interactive
>
> which, with no choices passed on the command-line, would provide the user with
> the default variant (the Poky Setup). The default choices would still have to
> be
> printed on the console to make it clear to the user what was selected.
>
We were trying to find the "equivalent set of commands" to pair with:
git clone <poky> -b LTS
source oe-init-build-env
bitbake <image>
and the equivalent would be using the `--non-interactive` so we played
around that to try to offer a minimum default for the reader.
But I - today - am still not completely convinced that making all the
choices at first is the best for the document flow. And using the
interactive way highlights too many "pokys" that the newcomer will not
understand
Anyway, if the community decided the default is not choosing for the
user, and let them choose, we (as tech writers) can only follow the
same.
We always knew bitbake-setup is in early stages, and there is a long
way until 6.0/may, that's why we started this conversation by asking
the basic questions: What is the expected list of features of
bitbake-setup by the next LTS and if bitbake-setup python package was
expected to be part of the LTS bundle before even start talking about
terminology. My goal (and I think I can say our goal and include
Otavio here) is more likely to be understanding where the community is
heading than making demands.
I appreciate all the attention,
Daiane
> [...]
> > 5. Fragment Discovery on OpenEmbedded Layer Index
> >
> > The OpenEmbedded Layer Index (https://layers.openembedded.org) is an
> > excellent resource for discovering layers. However, there is no equivalent
> > discovery mechanism for configuration fragments.
> >
> > Adding a tab or section for fragments would help users discover available
> > fragments and understand what problems they solve.
>
> Good idea IMO, as we already have machines and distros there, fragments would
> be
> a nice addition.
>
> Thanks for looking into this!
>
> Regards,
> Antonin
>
> --
> Antonin Godard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229367):
https://lists.openembedded.org/g/openembedded-core/message/229367
Mute This Topic: https://lists.openembedded.org/mt/117262508/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
