Loong Arch Linux 仓库管理工具需求

[wszqkzqk]

Loong Arch Linux 仓库管理工具需求

概述

本文档总结了Loong Arch Linux仓库管理工具的需求，涵盖了仓库管理端与包提交端的功能。工具的目标是确保包在不同仓库中的同步、版本管理的规范性以及包的依赖性和兼容性，方便开发者的开发与管理。

所有工具的配置文件及缓存文件存储均应当符合XDG user directories标准，统一放到对应用户目录下的devtools-loong64目录中。

仓库管理端需求

1. 包移动工具

• 功能描述：需要确保testing和staging仓库中的某个包及其基于它的重建（rebuild）同步移动到stable源中。
• 需求细节：
  • 包的更新和重建应能够同步自动移动到稳定仓库。
  • 需要确保包的版本和依赖关系在仓库间迁移时保持一致。

2. Lint检测工具

• 功能描述：该工具用于监控包的库位置变动或移除情况，跟进上游仓库的变动。
• 需求细节：
  • 需要检测并同步上游仓库中从core到extra或从extra到core的包迁移。
  • 需要处理上游的包的新增的重命名、提供、取代关系（例如，使用PKGBUILD的replace数组指向旧包，或者新的包provide旧包的情况）。
  • 包的移除需要在移除之前进行依赖性检测，确保不会破坏其他软件包。

3. 包损坏检测工具（可选）

• 功能描述：定期检测仓库中因soname变化导致链接丢失的包。
• 需求细节：
  • 检测由于共享库（.so文件）变动，链接至不存在的.so文件的包。
  • 提供损坏包的报告，供进一步修复。

4. debuginfod部署

• 功能描述：使用debuginfod服务分发调试包。
• 需求细节：
  • 管理调试包的上传与分发。

软件包提交端需求

1. 自动仓库选择

• 功能描述：确保上传的包自动选择合适的仓库。
• 需求细节：
  • 根据包在上游仓库的位置（core或extra）自动决定上传目标仓库。
  • 尽量能够自动判断上传的仓库是stable，testing还是staging，同时也可以手动指定。
  • 需要保证上传包的准确分类，避免错误上传到错误的仓库。

2. 版本号检测与警告

• 功能描述：当上传的包版本号与已有仓库中的包一致时，默认应阻止上传并发出警告。
• 需求细节：
  • 自动比较上传包的版本号与仓库中现有包的版本。
  • 如果版本一致，提示开发者并阻止重复上传。

3. soname检测与重建提示

• 功能描述：扫描上传包的soname变化，提示开发者是否需要重建包。
• 需求细节：
  • 扫描上传的包中soname变化，检查其是否有链接到旧的soname的包尚未重建。
  • 扫描上传的包中动态链接依赖，检查是否满足依赖关系。
  • 如果不满足，提示开发者重建需要重建的包或上传缺失的构建，并将包移入暂存区，待所有包上传完成后一起提交。

案例参考

• MSYS2 Package Page

[setarcos]

包移动工具

目前使用 staging 和 testing 的机会并不多，大部分都是等上游提交到 stable 才跟。

包损坏检测工具

这个就是 checksoname 脚本啊

自动仓库选择

core 和 extra 很容易，具体是 testing 还是 staging，必然要开发者选择啊，或者就根据上游来。

[wszqkzqk]

包移动工具

目前使用 staging 和 testing 的机会并不多，大部分都是等上游提交到 stable 才跟。

包损坏检测工具

这个就是 checksoname 脚本啊

自动仓库选择

core 和 extra 很容易，具体是 testing 还是 staging，必然要开发者选择啊，或者就根据上游来。

目前使用 staging 和 testing 的机会并不多，大部分都是等上游提交到 stable 才跟。

一年总有时间遇到，用到testing/staging的时候很容易遇到testing/staging积压（新打的包与原来的积压原因不同了却仍然滞留，这是有问题的），所以有这个需求。不一定立即实现。

另一方面，这种可选的/影响不大的/不着急的内容很适合分发为OSPP项目，即使外部参与者做得慢/做不出来也不会有致命影响。

这个就是 checksoname 脚本啊

我打算后面有空了规范一下路径，补充help和argparser，整合到devtools-loong64。loongshot最大的问题是没有强制手段保证每个开发者都安装。

完善的话可以加一个timer（再选择加一个公告页），方便所有开发者使用。

core 和 extra 很容易，具体是 testing 还是 staging，必然要开发者选择啊，或者就根据上游来。

可以默认按照上游来，支持手动选择。（所以说的是“尽量能够”）主要是考虑到手动指定出错的问题，我有时候就会出错。