如何同时支持Yocto的kirkstone与scarthgap分支？求最佳实践

各方案优劣对比 #

• 方案1：批量导入Kirkstone文件到新Scarthgap分支后调整
  • 好处：能快速拿到完整的现有配置，不会漏掉任何自定义修改，适合分支间差异大但核心逻辑没变的情况。
  • 问题：会带入大量Scarthgap不兼容的代码（比如配方语法、依赖版本、工具链变更），后续排查冲突、调整的工作量大，容易找不到问题根源。
• 方案2：挑选现有提交应用后少量调整
  • 好处：只迁移关键变更，冗余代码少，对目标分支的干扰小，适合自定义修改集中在特定提交的场景。
  • 问题：需要精准筛选提交，很容易漏掉隐性关联的修改（比如某个配方依赖的辅助脚本变更），后续可能出现功能缺失或构建失败。
• 方案3：逐个挑选提交并同步调整适配
  • 好处：边迁移边改，每一步都能验证代码是否可构建，方便调试，适合自定义修改多且分支差异大的情况。
  • 问题：耗时最长，需要对两个Yocto分支的变更细节门儿清，不然容易卡壳。
• 方案4：基于Kirkstone顶端分叉出Scarthgap分支后调整
  • 好处：保留Git历史关联，能清晰看到原始代码到适配版本的变化过程，后续把Kirkstone的共性修复同步到Scarthgap也更方便。
  • 问题：和方案1类似，需要手动处理分支间的API、语法差异，但历史追踪更清晰，排查问题有迹可循。

最佳实践建议 #

1. 优先用方案4搭基础框架
   从当前Kirkstone分支顶端创建专门的scarthgap分支（或临时用feature/scarthgap-adapt），这样Git历史完整保留，后续可以用git cherry-pick把Kirkstone上的共性bug修复同步过来。
2. 分模块适配，逐步验证
   把两个meta-*层按功能拆成模块（比如硬件驱动配方、应用程序配方、系统配置），逐个模块适配：
   • 先搞定核心构建配置：比如conf/layer.conf、bblayers.conf里的版本变量、层优先级；
   • 再调整依赖包版本：Scarthgap升级了不少基础包，得检查配方里的DEPENDS、RDEPENDS，还有SRC_URI、SRCREV是否兼容新版本；
   • 最后改自定义应用和驱动的配方语法：比如Yocto新版本可能废弃了某些do_*任务写法，或者改了变量命名规则。
3. 用Yocto工具辅助适配
   用devtool或recipetool快速查配方兼容性，比如recipetool checkrecipe <recipe-path>能直接揪出语法问题；同时参考官方的分支变更日志，重点关注BitBake、OpenEmbedded-Core的API变更，提前避开常见坑。
4. 建立双分支并行维护流程
   共性的bug修复或功能增强，先提交到Kirkstone，再用git cherry-pick同步到Scarthgap（注意适配分支差异）；Scarthgap的专属适配提交要单独标注，避免合并回Kirkstone时出冲突。
5. 自动化构建验证
   给两个分支配CI/CD流水线，每次提交自动触发构建，确保分支始终能正常构建，及时发现适配中的问题。

内容的提问来源于stack exchange，提问作者Jib