repotrack是唯一靠谱的依赖拉取工具，它能自动递归下载所有层级RPM依赖，避免yumdownloader漏掉间接依赖导致Failed dependency错误；必须严格匹配目标离线机的OS版本、架构和时间戳，并用容器验证安装完整性。
离线安装 GitLab 时依赖包下不全怎么办
直接结论：repotrack 是唯一靠谱的依赖拉取工具，yumdownloader 会漏掉间接依赖，导致离线安装卡在 Failed dependency 错误上。
常见错误现象是执行 yum localinstall gitlab-ce-*.rpm 后报类似：error: Failed dependencies: postgresql-server >= 9.6 is needed by gitlab-ce-16.10.0-ce.0.el8.x86_64，但你明明下载了 postgresql 主包——问题出在它依赖的 postgresql-libs、libpq 等子包没一起下。
- 用
repotrack --download_path=./deps gitlab-ce，它会自动递归解析并下载所有层级 RPM，包括systemd、rubygem-*、git-core等隐式依赖 - 必须提前在联网机上启用对应仓库源（如 CentOS 8 需
dnf install -y yum-utils，再dnf config-manager --set-enabled BaseOS AppStream） - 下载后建议跑一次完整性校验：
rpm -qpR *.rpm | grep "not found" | sort -u，若无输出说明依赖链闭合
不同发行版的依赖包不能混用
CentOS 7 的 gitlab-ce 依赖 glibc-2.17，而 openEuler 22.03 默认带 glibc-2.34，强行安装会触发 glibc version mismatch 错误，服务根本起不来。
实操中容易踩的坑是：在一台机器上下载所有包，复制到另一台不同 OS 的服务器上安装。结果不是缺包，而是包版本冲突。
- 确认目标离线机的系统信息：
cat /etc/os-release和uname -m，严格匹配下载环境 - OpenCloudOS、Anolis OS、openEuler 虽都基于 RHEL 源码，但默认启用的模块流（module streams）不同，
postgresql可能默认是 15 还是 12 版本，直接影响 GitLab 兼容性 - 如果必须跨发行版部署，优先选极狐 GitLab（
gitlab-jh），它对国产 OS 做过适配打包，依赖收敛更严格
下载后怎么验证依赖是否真能装上
别只看 rpm -qpR 输出，那只是静态声明；真正要模拟安装过程，否则到了离线环境才发现 postinstall 脚本调用的 /usr/bin/python3 实际指向的是 Python 3.9，而 GitLab CE 16.x 要求 Python 3.8+ 且带 distutils 模块——这个细节 rpm -qpR 根本不检查。
推荐在联网机上用干净容器验证：
- 启动临时环境：
podman run -it --rm -v $(pwd)/deps:/mnt/rpms:ro centos:8 - 在容器内执行：
dnf install -y /mnt/rpms/*.rpm --nogpgcheck --disablerepo='*' - 观察是否出现
Transaction test succeeded，失败则说明有隐藏冲突（比如两个包同时写同一配置文件）
GitLab 主包和依赖包的时间戳必须一致
GitLab 官方每两周发布一个新 patch 版本（如 16.11.3 → 16.11.4），但它的依赖包（如 redis、nginx）可能来自系统基础仓库，更新节奏完全不同。下载时间差超过一个月，大概率遇到 nginx-1:1.20.1-12.el8 和 GitLab 要求的 nginx >= 1.20.1-15 不匹配。
解决办法很简单但常被忽略：
- 下载前先同步时间：
timedatectl set-ntp true，确保联网机和目标离线机时区与 NTP 一致 - 记录下载命令执行时间，例如：
date +"%Y-%m-%d %H:%M" > download_time.log - 后续若需补依赖，必须用同一时间点的仓库快照（如 CentOS 8 的
BaseOS-8.8模块），而不是随便dnf update后再下
最麻烦的情况是：你下了 GitLab 16.11.4，但 Redis 依赖要求 redis-7.0.12-1，而系统仓库里最新只有 redis-7.0.10 ——这时得去 vault.centos.org 找历史包，而不是硬凑低版本。
