Loong Arch Linux 仓库管理工具需求

[wszqkzqk]

Loong Arch Linux 仓库管理工具需求

概述

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

目前几乎所有相关功能已经在LCPU loongshot或者devtools-loong64中实现，但是稳健性相对较低，相对缺乏规范性、整合性与通用性，部分功能操作上相对繁琐，缺乏原子性，也较难在开发者间统一行为。本RFC主要希望能够在已有工作上进行整合与重构，创建一个更加强大的仓库管理工具，为开发者带来更加方便的开发和维护体验。

所有工具的配置文件及缓存文件存储均应当符合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服务分发调试包。
• 需求细节：
  • 在现有的debuginfod服务基础上，优化调试包的上传与分发流程。
  • 尽量在仓库管理端集成功能，避免将过多逻辑放入开发者的提交端脚本，避免因网络连接不稳定、上传程序异常中断等带来的风险，尽量实现软件包更新上传的原子性。

软件包提交端需求

1. 自动仓库选择

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

2. 版本号检测与警告

• 功能描述：当上传的包版本号与已有仓库中的包一致时，默认应阻止上传并发出警告。
• 需求细节：
  • 自动比较上传包的版本号与仓库中现有包的版本。
  • 如果版本一致，提示开发者并阻止重复上传。
  • 目前的实现是检查pool/packages中是否有重复的软件包，可能已经足够合理。（？）
  • 新版本软件包上传后，配合仓库管理端移除仓库中的旧版本的软件包。

3. soname检测与重建提示

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

参考

• LCPU loongshot
• AUR - devtools-loong64
• 有关案例：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，必然要开发者选择啊，或者就根据上游来。

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