On Tue, 10 Sept 2024 at 17:02, Ryan Eatmon <[email protected]> wrote: > You are correct. I assumed that the string was the same format as the > SRC_URI. This might be a little confusing for users as that means we > have two different interpretations for repo strings.
> Then what good is the key value for? The current patch does not use > r_name except to look up the value under layers. Should we just make > the JSON have this as an array of repos instead of a named hash? > > Or is there some planned thing coming later that might make use of this key? Please keep in mind that the format for the set of layers in the 'sources' section follows precisely the json format used by layer setup tooling, which was discussed to death, and agreed with great difficulty quite some time ago, and then implemented in 'bitbake-layers create-layer-setup' that writes it out and oe-setup-layers that consumes it and pulls the layers from the network. Then there's an additional ['configuration']['bitbake-setup'] section, which is new, and specifies what to do after checking out the layers. This answers both of these points: 'sources' should list git repos in a way that can be given directly to git (so that we don't lock people into bitbake's git fetcher if they don't want to use that). And the key is used by oe-setup-layers as a 'name' of an entry to tell the user what is going on (bitbake-setup could do the same to hide the noisy git output, especially if we bolt on a nice interactive ncurses UI to it). > Ideally this would be locked to oe-core as that is what is intended. > But I'm not sure how best to do that. Indeed. Anyone can mimic oe-core in their rogue layer and be selected instead of the real oe-core. > Side topic, would it make sense to allow for the existence of a config > file in the repos that would allow them to "register" features that can > processed by bitbake-setup to configure various things that the layer > requires/offers? Right now we do this kind of thing for the > oe-setup-build script. But I could see the framework being useful for > this kind of thing. I suppose you are talking about config fragments, which are discussed in a separate thread, and have their own prototype. Bitbake-setup will certainly gain support for those, but they need to be agreed on and implemented first. As for allowing config entries that would direct bitbake-setup to run freeform shell scripts, I lean towards not supporting that. You can put them into 'targets' if you absolutely have to. We're trying to move away from custom and usually undocumented scripts with this effort. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2048): https://lists.openembedded.org/g/openembedded-architecture/message/2048 Mute This Topic: https://lists.openembedded.org/mt/108293734/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
