Hello, the next missing piece in the official setup and configuration management is configuration fragments, so I'd like to describe how I see them:
1. They are regular .inc files, residing in meta-somelayer/conf/fragments/category/. No special tooling is needed: you can 'cat fragment.inc > local.conf', or 'echo "require conf/fragments/category/fragment.inc" > local.conf' 2. There would be however a tool that allows standardized operations: add/remove/list/search. I'd suggest 'bitbake-config' or similar, which would basically reuse bitbake-layers infrastructure as much as possible. Bitbake-layers itself is already over-stuffed with various commands, and is more about layer management. 3. 'add' would simply add 'require fragment.inc' to local.conf, if it isn't already there. 'remove' would undo that, if it is there. 4. Each fragment must contain a description at the start, and the tooling would refuse to work with fragments without descriptions. Similar to machine configurations in oe-core. 5. The eventual goal is to reduce a typical local.conf to distro+machine+fragments. Any other settings in it should be seen as 'local hacks' that never leave a developer's machine. 6. The testing ground for all of this would be transferring the fragments from https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json into oe-core/poky. So that when someone gets feedback that their change failed on multilib, they don't have to go through complicated investigation of how to reproduce that. There are also fragments all over selftest that could be consolidated this way. 7. Layers are welcome and encouraged to publish their own fragments inside the layer. I love copy-paste-tweak programming without having to fully understand what is being tweaked, and I find it superior to 'reading documentation', especially when such documentation spends pages after pages describing design principles, syntax intricacies or rarely used command line options, and doesn't get to something I can copy paste until the end (and in worst cases doesn't offer that at all). Such fragments don't have to be directly usable; they can serve as a set of starting points. Anything else? Anything controversial above? Cheers, Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1964): https://lists.openembedded.org/g/openembedded-architecture/message/1964 Mute This Topic: https://lists.openembedded.org/mt/104485443/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
