Em qua., 14 de jan. de 2026 às 12:19, Antonin Godard via lists.openembedded.org <[email protected]> escreveu: > > 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? >
Honestly, especially when you are mentioning this in a context that you are talking about the Yocto Project as a whole, having the bitbake setup as prefix helps to avoid confusion. I don't mind about having the word configuration, even though my personal preference would be to not have that. > > > 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)? > This specific case is a configuration concept of the big setup JSON file. So when we specify the contents of the JSON, we will need to have this information. > [...] > > 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? What I mean by that is that we can skip this just because there is no option to be displayed to the user. Imagine that we are using the BitBake setup to provision a customer project. There are times that we don't need all those questions because we might have default values that we are going to use anyway. > > > 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. That is an interesting concept in my opinion. Either way, when there is no choices, we might just show the user what we are selecting, but not asking, because there is nothing to select. Also, some variables as the variant that we just discussed above. In case there is no variant available, we could just skip the questions as a whole. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229353): https://lists.openembedded.org/g/openembedded-core/message/229353 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]] -=-=-=-=-=-=-=-=-=-=-=-
