linux软件仓库维护核心是让每次发布可验证、可追溯、可回滚，需遵循语义化版本规范，完成构建、安装、运行时三类验证，原子化签名更新索引，并长期保留含.buildinfo的历史版本。
Linux软件仓库维护的核心是让每次发布可验证、可追溯、可回滚，而不是单纯把包扔上去就完事。关键在于建立一套与发行版生态对齐、兼顾安全与协作的发布管理机制。
版本号必须遵循语义化规范并体现在包元数据中
所有软件包的版本号需严格对应上游源码版本，并按主版本.次版本.修订号（如 2.4.1）格式表达：
- 主版本变更（2.x → 3.0）表示ABI不兼容，需同步更新
debian/changelog中的urgency=high并明确标注“breaks”依赖项 - 次版本变更（2.3 → 2.4）代表新增功能但保持ABI兼容，应在changelog中列出新特性条目
- 修订号变更（2.4.0 → 2.4.1）仅用于修复bug或安全补丁，要求复现问题并附测试用例
- Debian系包还须在
debian/control中声明Version:字段，且该值必须与debian/changelog首行版本一致
发布前必须完成三类验证动作
未经验证的包不得进入正式仓库，尤其不能推送到stable或main组件：
-
构建验证：在目标发行版最小化环境中运行
dpkg-buildpackage -us -uc，确认无编译错误、无缺失Build-Depends -
安装验证：使用
dpkg -i安装生成的.deb，检查/usr/bin路径下二进制是否存在、postinst脚本是否静默执行成功 - 运行时验证：启动服务或执行CLI命令，确认基础功能可用；若含GUI，需在对应桌面环境（GNOME/KDE/Wayland）下完成最小交互测试
仓库索引更新需原子化且带签名
使用reprepro管理Debian仓库时，每次发布后必须执行完整索引重建流程：
- 先通过
gpg --clearsign对Release文件签名，密钥应使用离线保管的专用GPG子密钥 - 执行
reprepro includedeb stable /path/to/pkg.deb后，立即运行reprepro export刷新Packages.gz和Release.gpg - Apache或Nginx需配置强制HTTPS，并在响应头中添加
X-Content-Type-Options: nosniff防止MIME混淆 - 用户端启用仓库前，必须导入对应公钥：
sudo apt-key add /path/to/repo.key（或更安全的gpg --dearmor方式）
历史版本必须长期保留且可定位
旧版本不是垃圾，而是回滚与审计的依据：
- 仓库目录结构应区分
pool/main/（源码包归档）与dists/stable/（当前可用索引），禁止删除pool中已发布的任何.dsc或.changes文件 - 每个
.deb包需附带.buildinfo文件，记录构建时间、内核版本、GCC版本及完整依赖树 - 建议在
dists/<dist>/changelogs/</dist>下存放解析后的变更日志，供apt changelog命令直接调用 - 所有发布操作须记录到Git仓库的
releases/分支，每次reprepro操作对应一个带tag的commit
