The Evolving Landscape of Yocto Project Setup: bitbake-setup vs. KAS
7 points by rw-rw-rw-
7 points by rw-rw-rw-
Huh, thanks for posting, Ive never heard of either of these tools, I use git submodules with a justfile, and check in my bblayers.conf and local.conf files.
Anyone who has ever used Yocto to create a custom Linux distribution has probably observed that the Yocto Project itself doesn’t offer a standardized method for the very first step
git submodules and oe-init-build-env (with a template) do this. But of course the config doesn't stay in sync after the setup.
I think submodules with recurse-submodules configured have way better UX than any external tool like bitbake-setup or repo.
I used to think the same way but after I spent years of my life with cleaning, fixing and upgrading Yocto setups of various clients I don't touch Yocto anymore without KAS, especially kas-container. No matter how hard you try, git submodules are an endless source of hassle.
Ohhhhhhh KAS is very interesting. The last time I really worked on a Yocto project was around 2017 or so and, yeah... it didn't take very long to understand how the whole layers and build process stuff worked. Managing all of the repos and submodules and all of that was by far the most frustrating piece, especially when it came to sitting down with my clients' engineers and trying to help them figure out effective procedures for handling all of that across multiple developers while still reviewing each others' work.
1 question and you might sell me. Does KAS/bitbake-setup solve the submodule problem of you having to merge groups of PRs bottom-up? Eg: if I have a program that is included in the company's meta-layer, which itself is a submodule in the overall image repo, a change in the base program needs at least:
And then when the PR/MR gets approved, you have to do all those steps again to merge so everything is pointing to the main branches at the end of it all.
That is my main complaint about submodule based dev, and if KAS or bitbake-setup solve those, I will switch immediately.
I don't think KAS solves any of these, since it's fundamentally based on a manifest with commit hashes (which is effectively the same thing git submodules do).
Maybe have a look at git subtrees? That lets you "merge" the meta layer's history into your top-level project by rewriting the commit to apply to on the layer's directory instead of the top-level.
On my projects I keep a project-specific layer on the top level so I don't have to update layers as often. I also keep small scripts (e.g. for configuration) in the top level instead of giving them their own repositories.
Well, KAS and most other tools let you also using a tag or branch name. If you can model said workflow with that, fine.
Git submodules can also follow a branch (for use with git submodule update). But you should really save the commit hash; otherwise you won't be able to get back to the exact state you had after someone updates the branch.
I have not had any issues with submodules. What problems did you encounter?
If git submodule work great for you, just use them. I made the experience that they are error prone and cumbersome to use, especially in large projects with many users where not everyone has git ninja skills. Others seem to face problems too. e.g.
Switching branches in a repository with submodules is a huge pain, especially if (like the Ansible repo) some branches have a normal subdirectory containing files in the same repo, and some branches have a submodule instead.