如何降级软件包版本 yum history和apt pinning技巧-linux运维-PHP中文网

降级软件包的常见原因包括新版本引入bug、兼容性问题、性能下降、特定环境需求或安全漏洞修复前的临时措施；2. 在centos/rhel系统中，应使用yum history list查看事务历史，通过yum history info <id>检查具体变更，并用yum history undo <id>回滚指定事务，但需注意依赖冲突、配置文件变更及数据丢失风险；3. 在debian/ubuntu系统中，可通过apt install package=version直接指定版本降级，或使用apt pinning机制，在/etc/apt/preferences.d/中设置pin-priority大于1000来强制安装旧版本并防止后续升级；4. 使用apt-cache policy <package>可查看包版本优先级，确保pinning规则生效；5. 降级操作存在依赖地狱、数据结构不兼容、安全漏洞重现和功能回退等风险，最佳实践包括操作前完整备份、在测试环境验证、分析依赖关系、逐步实施、详细记录并权衡替代方案。

如何降级软件包版本 yum history和apt pinning技巧

降级软件包版本，这在系统维护中可不是什么稀罕事，尤其是在Linux环境里。通常，当新版本引入了意想不到的问题、兼容性断裂，或者你只是需要回滚到一个已知稳定的状态时，

yum history

登录后复制

和

apt pinning

登录后复制

就成了解决这类燃眉之急的利器。它们一个在基于RPM的系统上提供事务性回滚，另一个则在基于Debian的系统上精细控制包的优先级和版本。

解决方案

当需要降级软件包时，对于CentOS/RHEL这类使用

yum

登录后复制

或

dnf

登录后复制

的系统，最直接且推荐的方式就是利用

yum history

登录后复制

功能进行事务回滚。它能让你像操作数据库事务一样，撤销之前的安装、更新或删除操作。而对于Debian/Ubuntu等使用

apt

登录后复制

的系统，虽然没有

history

登录后复制

这种直接回滚的机制，但

apt pinning

登录后复制

提供了一种强大的版本控制能力，通过设置优先级来决定安装哪个版本的软件包，或者直接指定版本号进行安装。

为什么有时候需要降级软件包？

说实话，我个人经历过好几次因为软件升级而“翻车”的惨痛教训。有一次，只是想更新一个看似不重要的库，结果整个核心服务都崩了，日志里全是莫名其妙的兼容性错误。当时真是焦头烂额，最后还是靠降级才把系统拉回来。所以，需要降级软件包的原因往往很实际：

引入了Bug或回归： 新版本可能修复了旧Bug，但又带来了新的Bug，甚至让原本正常的功能失效。这种情况下，降级是最快的止损方式。
兼容性问题： 某个应用程序或服务可能依赖于特定版本的库或运行时环境。新版本可能打破了这种依赖关系，导致应用无法启动或运行异常。
性能下降： 少数情况下，新版本在某些特定工作负载下表现不如旧版本，为了维持性能，可能需要回退。
安全漏洞修复前的权宜之计： 虽然通常是建议升级以修复安全漏洞，但如果新版本引入了更严重的问题，或者需要时间来测试，暂时降级到已知安全且稳定的旧版本，待问题解决后再升级也是一种策略（但这需要非常谨慎）。
特定项目或环境要求： 有些开发或测试环境，出于与生产环境保持一致或其他原因，可能需要固定在某个旧版本的软件包上。

使用Yum History进行回滚操作的具体步骤和注意事项

yum history

登录后复制

真的是个救命稻草。它记录了所有

yum

登录后复制

或

dnf

登录后复制

执行过的事务，包括安装、更新、删除等。

查看历史事务： 首先，你需要知道是哪个事务导致了问题。使用

yum history list

登录后复制

可以列出所有历史操作，每个操作都有一个ID、操作类型、日期、用户等信息。

yum history list

登录后复制

你会看到类似这样的输出：

ID     | Command line             | Date/Time        | Action(s)      | Altered
-------------------------------------------------------------------------------
10 | install nginx            | 2023-10-26 10:30 | Install        |    1
 9 | update                   | 2023-10-25 15:00 | Update         |   20 EE
 8 | remove httpd             | 2023-10-24 11:00 | Erase          |    1

登录后复制

检查特定事务详情： 找到你怀疑有问题的那个事务ID后，可以用
```
yum history info <ID>
```
登录后复制
来查看这个事务具体做了什么，安装、更新或删除了哪些包。
```
yum history info 9
```
登录后复制
这能帮你确认是不是这个操作导致了问题。
执行回滚： 确定了要回滚的事务ID后，就可以执行
```
yum history undo <ID>
```
登录后复制
命令。
```
yum history undo 9
```
登录后复制
这个命令会尝试撤销ID为9的事务。比如，如果ID为9的事务是更新了20个包，那么
```
undo 9
```
登录后复制
就会尝试把这20个包降级回它们更新前的版本。

注意事项：
- 并非万能：
```
yum history undo
```
  登录后复制
  并非总能完美回滚。如果回滚的包有复杂的依赖关系，或者回滚后会导致新的依赖冲突，它可能会失败。有时，你可能需要手动解决一些依赖问题，或者使用
```
--skip-broken
```
  登录后复制
  （但要非常小心，这可能导致系统不一致）。
- 文件变更：
```
yum history
```
  登录后复制
  主要处理软件包的安装、更新和删除。如果软件包更新过程中修改了配置文件，并且你手动对这些配置文件做了二次修改，
```
undo
```
  登录后复制
  操作通常不会恢复你的手动修改。它只会替换回软件包自带的旧版本配置文件，或者保留你的修改（这取决于rpm包的策略）。
- 数据丢失： 如果软件包的更新涉及到数据库模式的变更或者数据迁移，简单地降级软件包版本可能不会自动回滚数据，甚至可能导致数据损坏。在进行这类操作前，务必做好数据备份。
- 系统快照： 在执行任何重大更新或降级操作前，如果可能的话，最好先做一个虚拟机快照或者文件系统快照（比如LVM快照），这才是最保险的回滚手段。

Apt Pinning的工作原理及实际应用场景

apt pinning

登录后复制

（或者叫优先级设置）是Debian/Ubuntu系统管理软件包版本的一种非常灵活且强大的机制。它允许你告诉

apt

登录后复制

，对于某个特定的软件包，或者来自某个特定源的软件包，应该赋予什么样的优先级。

工作原理：

apt

登录后复制

在决定安装哪个版本的软件包时，会根据每个软件包版本及其来源（仓库）的“优先级”来选择。这些优先级通过

Pin-Priority

登录后复制

来设置，配置文件通常放在

/etc/apt/preferences

登录后复制

或

/etc/apt/preferences.d/

登录后复制

目录下。

优先级数值：
- >1000： 强制安装，即使是降级也会安装。非常危险，慎用。
- 990： 默认优先级，用于当前发行版中的软件包。
- 500： 默认优先级，用于非当前发行版（如
```
testing
```
  登录后复制
  、
```
unstable
```
  登录后复制
  ）或非官方源的软件包。
- 100： 如果没有更高优先级的版本，则安装。
- <0： 永不安装。
Pin规则： 你可以通过
```
Package
```
登录后复制
字段指定包名，
```
Pin
```
登录后复制
字段指定要匹配的源（例如，按发行版、组件、版本等）。

实际应用场景：

降重鸟

要想效果好，就用降重鸟。AI改写智能降低AIGC率和重复率。

113

查看详情

从测试版仓库安装特定包： 你的系统是稳定的Ubuntu LTS，但你需要某个软件的最新功能，而这个功能只在
```
testing
```
登录后复制
或
```
unstable
```
登录后复制
仓库有。你可以设置一个高优先级让
```
apt
```
登录后复制
只从
```
testing
```
登录后复制
仓库安装这一个包，而不影响其他包。
```
# /etc/apt/preferences.d/my-app-pinning.pref
Package: my-super-app
Pin: release n=jammy-updates,a=jammy-proposed,c=main
Pin-Priority: 600
```
登录后复制
这里我随便写了个例子，
```
Pin
```
登录后复制
规则可以更细致，比如
```
release a=stable
```
登录后复制
或
```
o=Debian
```
登录后复制
等。
防止某个包被升级： 如果你有一个关键应用，它只能在旧版本的某个库上运行，你可以通过设置
```
Pin-Priority
```
登录后复制
来“钉住”这个旧版本，防止它被意外升级。
```
# /etc/apt/preferences.d/legacy-lib-pinning.pref
Package: liblegacy-foo
Pin: version 1.0.0
Pin-Priority: 1001
```
登录后复制
这样，即使仓库里有
```
liblegacy-foo
```
登录后复制
的2.0.0版本，
```
apt
```
登录后复制
也会优先安装或保留1.0.0版本。
降级特定软件包： 如果你已经升级了某个包，但发现有问题，想要降级到之前的版本。
- 临时降级： 最简单粗暴的方法是直接指定版本号安装：
```
sudo apt install package-name=1.2.3-4
```
  登录后复制
  这种方法直接有效，但如果未来有更新，这个包还是会被升级。
- 通过Pinning降级并固定： 你可以找到你想要的旧版本所在的仓库（比如旧的快照仓库或手动添加的源），然后设置
```
Pin-Priority
```
  登录后复制
  来强制安装这个旧版本。这通常需要你有一个包含旧版本软件包的本地仓库或远程仓库。
操作步骤示例： 假设你想将
```
nginx
```
登录后复制
从最新版本降级到1.20.1。 a. 首先，确认你系统上有1.20.1版本的
```
nginx
```
登录后复制
包，或者你能找到一个包含这个版本的仓库。 b. 创建或编辑一个
```
preferences
```
登录后复制
文件，例如
```
/etc/apt/preferences.d/nginx-downgrade.pref
```
登录后复制
：
```
    Package: nginx
    Pin: version 1.20.1*
    Pin-Priority: 1001
```
登录后复制
```
`1.20.1*`表示所有以1.20.1开头的版本。`1001`的优先级会强制`apt`选择这个版本。
```
登录后复制
c. 更新
```
apt
```
登录后复制
缓存并尝试安装：
```
    sudo apt update
    sudo apt install nginx
```
登录后复制
```
`apt`会根据你设置的优先级，选择1.20.1版本的`nginx`进行安装（或降级）。
```
登录后复制
检查优先级： 随时可以使用
```
apt-cache policy <package-name>
```
登录后复制
来查看某个包的所有可用版本及其对应的优先级。
```
apt-cache policy nginx
```
登录后复制
这会清晰地展示每个版本来自哪个源，以及它的
```
Pin-Priority
```
登录后复制
是多少，帮助你理解
```
apt
```
登录后复制
为什么会选择某个版本。

Pinning的挑战：
```
apt pinning
```
登录后复制
非常强大，但也很容易配置错误，导致依赖问题或者无法升级。在使用前，务必理解其优先级规则，并在非生产环境进行充分测试。如果不再需要，记得移除或注释掉对应的
```
preferences
```
登录后复制
文件。

降级操作的风险与最佳实践

降级操作并非没有风险，有时甚至比升级更复杂。我见过不少因为降级不当导致系统半瘫痪的案例。

依赖地狱： 这是最常见的问题。一个软件包降级了，它所依赖的其他软件包可能仍然是新版本，导致依赖冲突。反之亦然，如果一个软件包被降级，依赖它的其他包可能无法找到所需的新功能。
数据结构不兼容： 某些应用程序在升级时会更新其内部数据结构（如数据库模式）。如果降级，旧版本的应用程序可能无法正确读取或处理新版本生成的数据，导致数据损坏或丢失。
安全风险： 降级到旧版本意味着你可能重新引入了已知的安全漏洞。这在面对互联网的服务器上尤其危险。
功能缺失： 降级后，你将失去新版本可能带来的性能优化、新功能或Bug修复。

最佳实践：

备份，备份，还是备份： 在执行任何降级操作前，无论是文件系统快照、数据库备份还是配置文件的备份，都应该成为你的肌肉记忆。这是最底线的保障。
测试先行： 永远不要在生产环境直接进行降级操作。先在与生产环境尽可能一致的测试或预生产环境中进行验证。
理解依赖关系： 在降级一个包之前，花点时间了解它的依赖项和被依赖项。
```
yum deplist <package>
```
登录后复制
或
```
apt-cache rdepends <package>
```
登录后复制
可以提供帮助。
文档记录： 记录你为什么降级、降级了哪些包、降级到哪个版本，以及你采取了哪些步骤。这对于未来的维护和故障排除至关重要。
权衡利弊： 在考虑降级时，问问自己：是否有其他方法可以解决问题？（例如，临时禁用某个功能，等待官方修复补丁，或者寻找社区补丁）。降级带来的风险是否小于当前问题的风险？
逐步操作： 如果需要降级多个包，尝试一个一个地降级，并验证每次操作后的系统状态。避免一次性处理太多变量。