Linux软件仓库维护核心是让每次发布可验证、可追溯、可回滚，需遵循语义化版本规范，完成构建、安装、运行时三类验证，原子化签名更新索引，并长期保留含.buildinfo的历史版本。
Linux 软件包版本同步与镜像仓库的维护管理，核心是让每次变更可验证、可追溯、可回滚。不是简单复制文件或定时拉取，而是围绕版本规范、验证流程、索引安全和历史留存建立闭环机制。
严格遵循语义化版本并注入元数据
所有软件包必须按 主版本.次版本.修订号（如 5.12.3）格式声明版本，且该值需在多个位置保持一致：
- debian/changelog 首行版本号必须与 debian/control 中的 Version 字段完全相同
- 主版本升级（如 4.x → 5.0）表示 ABI 不兼容，需在 changelog 中标注 urgency=high 并明确列出 breaks 依赖项
- 次版本升级（如 5.11 → 5.12）代表新增功能但兼容，应简要说明新特性
- 修订号升级（如 5.12.0 → 5.12.1）仅用于修复 bug 或安全补丁，须附带复现步骤与回归测试用例
发布前完成构建、安装、运行时三重验证
未经验证的包禁止进入 stable 或 main 组件，每类验证缺一不可：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
构建验证：在最小化目标环境中执行
dpkg-buildpackage -us -uc，确认无编译错误、Build-Depends 全部满足 -
安装验证：用
dpkg -i安装生成的 .deb，检查二进制是否落至 /usr/bin、postinst 是否静默成功退出 - 运行时验证：启动服务或运行 CLI 命令验证基础功能；含 GUI 的包需在对应桌面环境（GNOME/KDE/Wayland）下完成最小交互操作
索引更新必须原子化且签名可信
使用 reprepro 管理 Debian 仓库时，不能只推包不刷新索引：
- 每次 includedeb 后立即执行
reprepro export，确保 Packages.gz、Release、Release.gpg 全量一致 - Release 文件必须用离线保管的专用 GPG 子密钥签名：
gpg --clearsign -o Release.gpg Release - Web 服务（Nginx/Apache）需强制 HTTPS，并添加响应头
X-Content-Type-Options: nosniff - 客户端启用仓库前，必须导入公钥——推荐方式为
gpg --dearmor导入到 /usr/share/keyrings/，而非已弃用的 apt-key
历史版本长期保留并具备可审计性
旧包不是冗余数据，而是回滚与合规审计的关键依据：
- pool/main/ 下所有 .dsc、.changes、.deb 文件禁止删除，哪怕已不在当前 Release 中
- 每个 .deb 必须附带同名 .buildinfo 文件，记录构建时间、内核版本、GCC 版本及完整依赖树
- dists/<dist>/changelogs/ 目录建议存放解析后的纯文本变更日志，供
apt changelog直接调用 - 若用 apt-mirror 拉取全量镜像，需确认上游支持 archive mode（如 Ubuntu 默认开启），并配置 clean.sh 仅清理过期 .deb，保留元数据
