CentOS dropped 兼容性测试与处理指南
一、含义与现状
- 在软件源或构建日志中看到 “Dropped”，通常表示某个软件包因不满足当前系统的架构、版本或依赖约束而被仓库或构建系统跳过/拒绝，并非系统本身“被丢弃”。常见触发因素包括：系统版本过旧或已 EOL、仓库元数据过期、依赖无法满足、架构不匹配等。
- 项目层面，CentOS 7 已于 2024-06-30 结束官方支持；CentOS 8 在 2021 年底停止维护并转向 CentOS Stream（滚动更新、与 RHEL 的兼容性不同于传统的 CentOS Linux）。这意味着旧版本仓库可能不可用或包被移出，从而更容易出现 “Dropped” 现象。
二、快速自检清单
- 确认系统与内核：cat /etc/os-release；rpm -q centos-release；hostnamectl；uname -a。重点核对是否为 CentOS 7/8/Stream、系统架构（如 x86_64）、以及内核系列是否匹配目标软件要求。
- 核对仓库与元数据：yum clean all && yum makecache（或 dnf clean all && dnf makecache）；检查 /etc/yum.repos.d/ 中是否仍启用已 EOL 或失效的仓库（如指向 vault 的旧源）。
- 复现与定位：执行安装/构建命令时添加 -v/–verbose 或 –debug，从输出中定位是“架构不匹配”“依赖缺失/冲突”还是“仓库 404/签名失败”导致的 Dropped。
三、兼容性测试步骤
- 基线信息采集：记录目标系统与内核版本、已安装关键依赖版本、glibc 版本、编译器/语言运行时版本（如 glibc、gcc、python3）。
- 依赖与二进制兼容：对关键二进制/库使用 ldd 检查缺失依赖；验证与 RHEL 的二进制兼容性（CentOS 传统上与同代 RHEL 保持高兼容性，但跨主版本或跨发行版如 Ubuntu 往往不兼容）。
- 仓库可达性与包可用性：确保 base/updates/extras 等仓库可访问且元数据有效；对 EOL 系统，必要时临时指向 vault.centos.org 的归档仓库，仅用于兼容性验证与过渡，不作为长期方案。
- 最小复现与回归：在干净 chroot/容器/虚拟机中仅安装目标依赖进行安装与启动测试；覆盖升级/回滚路径，验证配置文件、数据路径、权限与服务的启停行为。
四、处理与迁移建议
- 短期处置（验证/过渡）：对 EOL 系统，临时启用归档源完成兼容性验证与必要回滚；同时规划迁移窗口，避免长期停留在无安全更新的环境。
- 长期方案（按场景选择）：
- 生产稳定与长期支持：迁移至与 RHEL 1:1 二进制兼容的 Rocky Linux 或 AlmaLinux，保持生态与兼容性。
- 开发/云原生与提前体验 RHEL 变更：使用 CentOS Stream（滚动上游，适合 CI/CD 与特性验证）。
- 需要较新软件栈与开发体验：可选 Fedora Linux；若需企业级支持与广泛架构适配，可考虑 openSUSE Leap 等替代发行版。