yum 安装某个软件失败，出错的却可能是另一个已启用仓库。2018 年安装 GitLab 后，再执行 yum install 遇到了 gitlab_gitlab-ce-source 的元数据错误；先定位失败仓库，再判断当前任务是否需要它。

错误已经给出了仓库 ID

Cannot retrieve repository metadata (repomd.xml) for repository:
gitlab_gitlab-ce-source. Please verify its path and try again

这里的重点是 gitlab_gitlab-ce-source，不是猜测“要安装的软件包坏了”。当年在 /etc/yum.repos.d/gitlab_gitlab-ce.repo 中找到同名段，将 enabled=1 改成 enabled=0，后续操作绕过了这个错误。

正确目录是 /etc/yum.repos.d；旧稿一处写成 yum.repost.d，是拼写错误。

单次禁用与长期配置分开

旧 yum 支持按命令临时禁用指定仓库。例如查看其他仓库状态：

yum --disablerepo=gitlab_gitlab-ce-source repolist

这是检查仓库范围的例子，不会修复该 source 仓库。若当前任务依赖其中的软件，禁用后可能无法完成。yum 官方项目手册

长期修改 enabled 前，应保存对应 .repo 配置并确认影响范围；恢复时只恢复这一段的预期状态，不覆盖文件中其他配置。source 仓库与二进制包仓库也不要仅凭名字合并处理。

为什么元数据取不到

需要继续检查实际配置 URL、网络解析与连接、HTTP 状态、证书及仓库是否仍提供该路径。旧记录没有保存这些证据，因此“禁用后能继续”只能说明隔离了失败源，不能证明根因是 GitLab 安装本身。

不要为绕过问题关闭 gpgcheck、TLS 证书验证或所有仓库。对于旧 CentOS 环境，还应按系统生命周期寻找合适的维护和升级方案，不能把 2018 年的仓库地址当成今天的安装入口。

确认处理结果时，既要看当前任务是否使用了预期仓库，也要记录被隔离仓库的后续修复安排。