我安装了一个基于 RPM 的发行版（如 Fedora），它的软件包使用一组 RPM 存储库，我想将其更改为使用另一组 RPM 存储库，从而有效地将其转换为另一个发行版（如 CentOS）。我需要在不重新安装系统的情况下完成此操作。
我想这样做的原因是因为这台机器是我的组织给我的，并且我们被告知“不要在上面安装任何其他操作系统”。然而，它使用了一组不起眼的存储库，这些存储库获取安全更新的速度似乎相当慢，而且我真的不能相信该存储库会得到正确维护。我确实拥有机器的 root 访问权限，根据 IT 部门的说法，这不算是“重新安装”。
但是，此存储库中的软件包的版本名称带有供应商后缀（例如，来自 Ubuntu 的软件包的版本为1:13.0.1-2ubuntu2）。特别是某些系统软件包systemd具有这样的功能。 AFAICT，这意味着依赖于 的所有内容systemd以及systemd其本身都必须重新安装，因此系统的大部分内容将被删除，然后在系统运行时重新安装，这似乎是破坏我的安装的一种非常快速的方法。
我考虑过的一种可能的解决方案是：从我的安装的依赖树的叶子开始，
- 从新的repo下载相应的包
- 编辑它，使其依赖项版本与旧存储库的版本匹配
- 在现有软件包上安装此软件包
- 如果此包被任何其他包依赖，请将其替换为其未编辑的版本（因为此包现在具有新名称，而编辑后的包依赖于旧名称）
- 对依赖树的每个深度依次执行此操作
该策略是否有效？我还需要哪些其他选项来执行此类升级？
答案1
该部分
2ubuntu2称为版本号。包管理器使用它来比较具有相同版本的包的两个变体。包管理器将其视为纯粹的字母数字。没有其他语义。该部分ubuntu2称为 dist-tag。它用于帮助人们了解该软件包适用于哪个系统。但包管理器不评估该值。您可以在 RHEL9 上安装“el5”软件包，在 RHEL5 上安装“el9”软件包。通常，包装要求会阻止您。但如果你的包没有其他依赖项，那么你就可以做到。这种做法并没有什么问题。RPM 软件包的升级方式是安装新的软件包，然后删除旧的软件包。因此，即使您这样做
dnf upgrade，系统也应该始终运行。即使在交易过程中。依赖关系非常复杂，逐个升级软件包几乎是不可能的。在一笔大交易中，你会有更好的运气。
从 CentOS中获取文件
/etc/yum.repos.d并将其放入您的计算机中/etc/yum.repos.并执行dnf upgrade或dnf distro-sync可能会执行该工作。我想说有 80% 的机会它会起作用。但剩下的 20% 就很糟糕了。在更好的情况下，您会在事务之前获得损坏的依赖关系。你可能会以某种方式解决它。在最坏的情况下，您在交易过程中会遇到一些错误。一切都会崩溃，你会得到一个无法启动的系统。很难提前猜测。问题是你很可能是世界上第一个这样做的人。这些先驱者会发现错误。
我会非常犹豫是否要使用生产机器来完成此操作。至少您应该首先在相同配置的某些虚拟机上尝试此升级路径。