标签 DNF 下的文章

你好,技术兄弟,最近红帽发布了最新的操作系统 RHEL 9,RHEL 9 满足了混合云的所有要求。它可以安装在物理服务器、虚拟机和容器镜像中。

当我们没有订阅的时候,想安装软件包来做实验,那么设置本地的 Yum 或 DNF 仓库将是很方便的。

在本指南中,我们将介绍如何在 RHEL 9 上使用 DVD 或 ISO 文件一步一步地创建本地 Yum/DNF 资源库。

创建本地 Yum/DNF 资源库的先决条件:

  • 最小化安装 RHEL 9 系统
  • 具有管理权限的 sudo 用户
  • RHEL 9 DVD 或 ISO 文件

1)挂载 RHEL 9 ISO 文件或 DVD

我们假设 RHEL 9 iso 文件已经被复制到系统中。运行下面的挂载命令,将 ISO 文件挂载到 /opt/repo 文件夹。

$ sudo mkdir /var/repo
$ sudo mount -o loop rhel-baseos-9.0-x86_64-dvd.iso /var/repo/

Mount-RHEL9-ISO-File-Command

如果是 DVD 光盘,运行:

$ sudo mount /dev/sr0 /var/repo/

2)在 /etc/yum.repos.d/ 目录中创建仓库文件

/etc/yum.repos.d/ 目录下创建一个名为 “rhel9-local.repo` 的仓库文件,内容如下:

$ sudo vi /etc/yum.repos.d/rhel9-local.repo
[Local-BaseOS]
name=Red Hat Enterprise Linux 9 - BaseOS
metadata_expire=-1
gpgcheck=1
enabled=1
baseurl=file:///var/repo//BaseOS/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

[Local-AppStream]
name=Red Hat Enterprise Linux 9 - AppStream
metadata_expire=-1
gpgcheck=1
enabled=1
baseurl=file:///var/repo//AppStream/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

保存并关闭该文件。

RHEL8-Local-Repo-File

3)刷新 Yum/DNF 和订阅管理器的缓存

执行以下命令来清理 Yum 或 DNF 和订阅管理器的缓存。

$ sudo dnf clean all
$ sudo subscription-manager clean

DNF-Subscription-Manager-Clean

在上面的输出中,我们得到一个警告信息 This system is not registered with an entitlement(系统没有注册权限)。所以,为了抑制这个警告信息,编辑文件 /etc/yum/pluginconf.d/subscription-manager.conf,将参数 enabled=1 改为 enabled=0

$ sudo vi /etc/yum/pluginconf.d/subscription-manager.conf

Disable-Subscription-Parameter-RHEL-9

保存并退出该文件。

4)使用本地仓库安装软件包

现在我们都准备好测试我们的本地仓库了。运行下面的命令来查看配置仓库。

$ sudo dnf repolist

输出:

DNF-Repolist-RHEL-9

现在,试试用 dnf 命令通过上面配置的本地仓库安装软件包。

$ sudo dnf install nfs-utils

输出:

Install-RPM-Package-via-local-repo-rhel9

Package-Installation-Completion-RHEL9-DNF-Command

完美,上述输出证实了 nfs-utils 包及其依赖项已经通过本地配置的 Yum 或 DNF 仓库成功安装。

这就是本指南的全部内容。我希望你觉得它有参考价值。请在下面的评论区发表你的疑问和反馈。


via: https://www.linuxtechi.com/create-local-yum-dnf-repository-rhel/

作者:Pradeep Kumar 选题:lkxed 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解如何在 Linux 上使用 dnf 命令安装软件包,然后下载我们的速查表,让正确的命令触手可及。

 title=

在计算机系统上安装应用程序非常简单:就是将档案(如 .zip 文件)中的文件复制到目标计算机上,放在操作系统预期放应用程序的位置。因为我们中的许多人习惯于使用花哨的安装“向导”来帮助我们在计算机上安装软件,所以这个过程似乎在技术上应该比实际更复杂。

然而,复杂的是,是什么构成了一个程序?用户认为的单个应用程序实际上包含了分散在操作系统中的软件库的各种依赖代码(例如:Linux 上的 .so 文件、Windows 上的 .dll 文件和 macOS 上的 .dylib 文件)。

为了让用户不必担心这些程序代码之间的复杂的互相依赖关系, Linux 使用 包管理系统 package management system 来跟踪哪些应用程序需要哪些库,哪些库或应用程序有安全或功能更新,以及每个软件会附带安装哪些额外的数据文件。包管理器本质上是一个安装向导。它们易于使用,提供了图形界面和基于终端的界面,让你的生活更轻松。你越了解你的发行版的包管理器,你的生活就会越轻松。

在 Linux 上安装应用程序

如果你在使用 Linux 桌面时,偶尔想要安装一个应用程序,那么你可能正在寻找 GNOME “软件”,它是一个桌面应用程序浏览器。

 title=

它会按你的预期工作:点击它的界面,直到你找到一个看起来有用的应用程序,然后单击 “安装” 按钮。

或者,你可以在 GNOME “软件” 中打开从网络下载的 .rpm.flatpakref 软件包,以便它进行安装。

但如果你更倾向于使用命令行,请继续阅读。

用 dnf 搜索软件

在安装应用程序之前,你可能需要确认它是否存在于你的发行版的服务器上。通常,使用 dnf 搜索应用程序的通用名称就足够了。例如,假设你最近阅读了 一篇关于 Cockpit 的文章,并决定尝试一下。你可以搜索 cockpit 验证该发行版是否包含它:

$ dnf search cockpit
 Last metadata expiration check: 0:01:46 ago on Tue 18 May 2021 19:18:15 NZST.
 ==== Name Exactly Matched: cockpit ====
 cockpit.x86_64 : Web Console for Linux servers

==== Name & Summary Matched: cockpit ==
 cockpit-bridge.x86_64 : Cockpit bridge server-side component
 cockpit-composer.noarch : Composer GUI for use with Cockpit
 [...]

有一个精确的匹配。上面列出的匹配的软件包名为 cockpit.x86_64,但名称中的 .x86_64 部分仅表示它兼容该 CPU 架构。默认情况下,你的系统会安装适配当前 CPU 架构的软件包,因此你可以忽略该扩展名。所以你确认你要查找的软件包确实简称为 cockpit

现在你可以放心地使用 dnf install 安装它。 此步骤需要管理员权限:

$ sudo dnf install cockpit

一般来说,这就是典型的 dnf 工作流:搜索并安装。

然而,有时 dnf search 的结果并不清晰,或者你想要关于一个软件包的更多信息,而不仅仅是它的通用名称。有一些相关的 dnf 子命令,具体取决于你想要的信息。

软件包的元数据

如果你觉得你的搜索已 接近 想要的结果,但还不确定,查看软件包的元数据通常会有所帮助,例如项目的网址和描述。要获取此信息,请使用顾名思义的 dnf info 命令:

$ dnf info terminator
Available Packages
Name         : terminator
Version      : 1.92
Release      : 2.el8
Architecture : noarch
Size         : 526 k
Source       : terminator-1.92-2.el8.src.rpm
Repository   : epel
Summary      : Store and run multiple GNOME terminals in one window
URL          : https://github.com/gnome-terminator
License      : GPLv2
Description  : Multiple GNOME terminals in one window.  This is a project to produce
             : an efficient way of filling a large area of screen space with
             : terminals. This is done by splitting the window into a resizeable
             : grid of terminals. As such, you can  produce a very flexible
             : arrangements of terminals for different tasks.

这个信息告诉你可用软件包的版本、在你系统中注册的哪一个存储库提供了它、该项目的网站以及详细的功能描述。

哪个软件包提供的这个文件?

软件包名称并不总是与你要查找的内容相匹配。例如,假设你正在阅读的文档告诉你必须安装名为 qmake-qt5 的东西:

$ dnf search qmake-qt5
No matches found.

dnf 数据库非常广泛,因此你不要局限于搜索完全匹配的内容。你可以使用 dnf provides 命令来了解你正在寻找的东西是否作为某个更大的软件包的一部分而提供:

$ dnf provides qmake-qt5
qt5-qtbase-devel-5.12.5-8.el8.i686 : Development files for qt5-qtbase
Repo        : appstream
Matched from:
Filename    : /usr/bin/qmake-qt5

qt5-qtbase-devel-5.15.2-3.el8.x86_64 : Development files for qt5-qtbase
Repo        : appstream
Matched from:
Filename    : /usr/bin/qmake-qt5

可以确认应用程序 qmake-qt5 是名为 qt5-qtbase-devel 的软件包的一部分。它还告诉你,该应用程序会安装到 /usr/bin,因此你知道了安装后它的确切位置。

软件包中包含哪些文件?

有时我发现自己会从完全不同的角度来对待 dnf。有时,我已经确认我的系统上安装了一个应用程序;我只是不知道我是怎么得到它的。还有一些时候,我知道我安装了一个特定的软件包,但我不清楚这个软件包到底在我的系统上安装了什么。

如果你需要对包的 有效负载 payload 进行 “ 逆向工程 reverse engineer ”,可以使用 dnf repoquery 命令和 --list 选项。这将查看存储库中有关软件包的元数据,并列出该软件包提供的所有文件:

$ dnf repoquery --list qt5-qtbase-devel
/usr/bin/fixqt4headers.pl
/usr/bin/moc-qt5
/usr/bin/qdbuscpp2xml-qt5
/usr/bin/qdbusxml2cpp-qt5
/usr/bin/qlalr
/usr/bin/qmake-qt5
/usr/bin/qvkgen
/usr/bin/rcc-qt5
[...]

这些列表可能很长,使用 less 或你喜欢的分页命令配合管道操作会有所帮助。

移除应用程序

如果你决定系统中不再需要某个应用程序,可以使用 dnf remove 卸载它,该软件包本身安装的文件以及不再需要的任何依赖项都会被移除:

$ dnf remove bigapp

有时,你发现随着一个应用程序一起安装的依赖项对后来安装的其他应用程序也有用。如果两个包需要相同的依赖项,dnf remove 不会 删除依赖项。在安装和卸载大量应用程序之后,孤儿软件包散落各处的现象并不少见。大约每年我都要执行一次 dnf autoremove 来清除所有未使用的软件包:

$ dnf autoremove

这不是必需的,但这是一个让我的电脑感觉更好的大扫除步骤。

了解 dnf

你对包管理器的工作方式了解得越多,在必要时安装和查询应用程序就越容易。即便你不是 dnf 的重度使用者,当你发现自己与基于 RPM 的发行版交互时,了解它也会很有用。

告别 yum 后,我最喜欢的包管理器之一是 dnf 命令。虽然我不喜欢它的所有子命令,但我发现它是目前最健壮的 包管理系统 package management system 之一。 下载我们的 dnf 速查表 习惯该命令,不要害怕尝试一些新技巧。一旦熟悉了它,你可能会发现很难使用其他任何东西替代它。

dnf 速查表

via: https://opensource.com/article/21/6/dnf-linux

作者:Seth Kenlon 选题:lujun9972 译者:hanszhao80 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

包管理器提供大致相同的功能:安装、管理和移除应用,但是它们还是有一些不一样的地方。

 title=

在 Linux 系统上获取一个应用 有多种方式。例如,有新的 Flatpak 和容器方式,也有 DEB 和 RPM 这样一直以来经过考验的方式。

并没有一种通用的可以用于所有的操作系统的应用安装程序。如今,因为有无数的开发者发布软件,这导致了大部分的操作系统使用了应用商店(包括第一方和第三方)、拖放式安装,还有安装向导。不同的开发者对于他们发布的代码有不同的需求,这直接导致了他们所选择的安装方式的不同。

Linux 开创了一种通过命令行安装、管理、移除应用的包管理器的概念。aptdnf 就是两种较为常见的包管理器。apt 命令是用来管理 DEB 格式的包,dnf 命令是用来管理 RPM 格式的包。这两种包管理器在理论上并不是完全互斥的,尽管在实际的实践中,Linux 发行版通常只会使用到其中的一种。理论上,这两种命令可以运行在同一个系统上,但是会造成安装包的重叠,版本控制也会更加困难,命令也会是冗余的。然而,如果你是在一个混合的 Linux 环境下工作,比如你的工作站运行的是一个发行版,同时需要与运行另外一种发行版的服务器进行交互,那么你最好同时掌握这两种包管理器。

搜索应用

当你通过包管理器安装一个应用时,你需要先知道包的名称。通常,应用的名称和包的名称是一样的。dnfapt 验证要安装的包名的过程是完全相同的。

$ sudo dnf search zsh
====== Name Exactly Matched: zsh ======
zsh.x86_64 : Powerful interactive shell
[...]

使用 apt:

$ sudo apt search zsh
Sorting... Done
Full Text Search... Done
csh/stable 20110502-4+deb10u1 amd64
  Shell with C-like syntax

ddgr/stable 1.6-1 all
  DuckDuckGo from the terminal

direnv/stable 2.18.2-2 amd64
  Utility to set directory specific environment variables

draai/stable 20180521-1 all
  Command-line music player for MPD
[...]

如果想通过 apt 更快的获取相关的搜索结果,你可以使用 正则表达式

apt search ^zsh
Sorting... Done
Full Text Search... Done
zsh/stable 5.7.1-1 amd64
  shell with lots of features
[...]

查找应用程序包

有一些命令是与其它命令捆绑在一起的,都在一个包中。在这种情况下,你可以通过包管理器去了解哪个包提供了你需要的命令。dnfapt 命令在如何搜索这类元数据上是有区别的。

使用 dnf

$ sudo dnf provides pgrep
procps-ng-3.3.15-6.el8.x86_64 : System and process monitoring utilities
Repo        : baseos
Matched from:
Filename    : /usr/bin/pgrep

apt 命令使用子命令 apt-file。要使用 apt-file,你必须先安装它,然后提示它更新缓存:

$ sudo apt install apt-file
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following additional packages will be installed:
  libapt-pkg-perl libexporter-tiny-perl liblist-moreutils-perl libregexp-assemble-perl
The following NEW packages will be installed:
  apt-file libapt-pkg-perl libexporter-tiny-perl liblist-moreutils-perl libregexp-assemble-perl
0 upgraded, 5 newly installed, 0 to remove and 14 not upgraded.
Need to get 297 kB of archives.
After this operation, 825 kB of additional disk space will be used.
Do you want to continue? [Y/n] y

$ sudo apt-file update
[...]

你可以通过 apt-file 搜索命令。你可以使用此命令进行广泛的全局搜索,但假如你知道命令的执行路径,它会更准确:

$ sudo apt-file search /usr/bin/pgrep
pgreplay: /usr/bin/pgreplay              
procps: /usr/bin/pgrep

安装应用程序

使用aptdnf 安装应用程序基本上是相同的:

$ sudo apt install zsh

使用 dnf,你可以使用同样的方式来安装一个包:

$ sudo dnf install zsh

许多基于 RPM 的发行版都具有组包安装的特性,它会将有时表面相关的应用程序收集到一个易于安装的目标中。例如,Fedora 中的 Design Suite 组包就包含流行的创意应用程序。那些想要某一个创意应用程序的艺术家可能也想要类似的应用程序,选择安装一整个组包一个简单而快速的方法,可以合理地开始建立一个数字工作室。你可以通过 group list 来查看可用的组包(使用 -v 来查看不带空格的组名):

$ sudo dnf group list -v
[...]
Available Groups:
   Container Management (container-management)
   RPM Development Tools (rpm-development-tools)
   Design Suite (design-suite)
   Development Tools (development)
[...]

使用 group install 子命令安装 RPM 组包:

$ sudo dnf group install design-suite

你可以使用 @ 符号来减少输入:

$ sudo dnf install @design-suite

更新应用程序

使用包管理器的一个优点是,它知道所有已经安装的应用。这样你不必去寻找应用程序的更新版本。相反,你可以通过包管理器去获取更新的版本。

dnfapt 使用的子命令略有不同。因为 apt 保存了一个需要定期更新的缓存信息,它使用 upgrade 子命令来更新应用程序:

$ sudo apt upgrade

相比之下,dnf 命令在你每次使用时都会更新元信息,所以 updateupgrade 子命令是可以互换的:

$ sudo dnf upgrade

这等同于:

$ sudo dnf update

移除应用程序

如果你曾经尝试在任何一个平台上手动删除一个应用程序,你就会知道,应用程序删除后,在硬盘上会残留各种文件,比如首选项文件、数据或图标。所以包管理器的另一个优点是,包管理器管理着包中安装的每一个文件,可以很方便的删除:

$ sudo dnf remove zsh

remove 子命令也适用于 apt

$ sudo apt remove zsh

使用 apt 命令删除一个包并不会删除已修改的用户配置文件,以防你意外删除了包。如果你想通过 apt 命令删除一个应用及其配置文件,请在你之前删除过的应用程序上使用 purge 子命令:

$ sudo apt purge zsh

aptdnf 都不会删除家目录中的数据和配置文件(即使使用 purge 子命令)。如果想要从家目录中删除数据,你必须手动操作(通常你可以在 ~/.config~/.local 文件中找到)。

了解包管理

无论你选择的发行版支持的是 apt 还是 dnf,这些命令的用途大致相同。它们可以帮助你安装、更新和移除包。这两种包管理器是目前最通用的包管理器。它们的语法元素在很大程度上是相同的,所以在两者之间切换非常容易。

aptdnf 还有一些高级功能,例如仓库管理,但这些功能并不像你使用 searchinstall 那样频繁。

无论你更经常使用哪种包管理器,你都可以下载我们的 apt 备忘单dnf 备忘单,以便你在最需要的时候可以查询使用语法。


via: https://opensource.com/article/21/7/dnf-vs-apt

作者:Seth Kenlon 选题:lujun9972 译者:perfiffer 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

由于 Yum 中许多长期存在的问题仍未得到解决,因此 Yum 包管理器已被 DNF 包管理器取代。这些问题包括性能差、内存占用过多、依赖解析速度变慢等。

DNF 使用 libsolv 进行依赖解析,由 SUSE 开发和维护,旨在提高性能。

Yum 主要是用 Python 编写的,它有自己的应对依赖解析的方法。它的 API 没有完整的文档,它的扩展系统只允许 Python 插件。

Yum 是 RPM 的前端工具,它管理依赖关系和资源库,然后使用 RPM 来安装、下载和删除包。

为什么他们要建立一个新的工具,而不是修复现有的问题呢?

Ales Kozamblak 解释说,这个修复在技术上是不可行的,而且 Yum 团队还没有准备好立即接受修改。

另外,最大的挑战是,Yum 有 56000 行代码,但 DNF 只有 29000 行代码。

所以除了分叉,没有办法解决。

不过 Yum 的运行情况还算可以。

编号DNF(Dandified YUM)YUM(Yellowdog Updater, Modified)
1DNF 使用 libsolv 来解析依赖关系,由 SUSE 开发和维护YUM 使用公开的 API 来解析依赖关系
2API 有完整的文档API 没有完整的文档
3由 C、C++、Python 编写的只用 Python 编写
4DNF 目前在 Fedora、RHEL 8、CentOS 8、OEL 8 和 Mageia 6/7 中使用YUM 目前在 RHEL 6/7、CentOS 6/7、OEL 6/7 中使用
5DNF 支持各种扩展Yum 只支持基于 Python 的扩展
6API 有良好的文档,因此很容易创建新的功能因为 API 没有正确的文档化,所以创建新功能非常困难
7DNF 在同步存储库的元数据时,使用的内存较少在同步存储库的元数据时,YUM 使用了过多的内存
8DNF 使用满足性算法来解决依赖关系解析(它是用字典的方法来存储和检索包和依赖信息)由于使用公开 API 的原因,Yum 依赖性解析变得迟钝
9从内存使用量和版本库元数据的依赖性解析来看,性能都不错总的来说,在很多因素的影响下,表现不佳
10DNF 更新:在 DNF 更新过程中,如果包中包含不相关的依赖,则不会更新YUM 将在没有验证的情况下更新软件包
11如果启用的存储库没有响应,DNF 将跳过它,并继续使用可用的存储库处理事务如果有存储库不可用,YUM 会立即停止
12dnf updatednf upgrade 是等价的在 Yum 中则不同
13安装包的依赖关系不更新Yum 为这种行为提供了一个选项
14清理删除的包:当删除一个包时,DNF 会自动删除任何没有被用户明确安装的依赖包Yum 不会这样做
15存储库缓存更新计划:默认情况下,系统启动后 10 分钟后,DNF 每小时会对配置的存储库检查一次更新。这个动作由系统定时器单元 dnf-makecache.timer 控制Yum 也会这样做
16内核包不受 DNF 保护。不像 Yum,你可以删除所有的内核包,包括运行中的内核包Yum 不允许你删除运行中的内核
17libsolv:用于解包和读取资源库。hawkey: 为 libsolv 提供简化的 C 和 Python API 库。librepo: 提供 C 和 Python(类似 libcURL)API 的库,用于下载 Linux 存储库元数据和软件包。libcomps: 是 yum.comps 库的替代品。它是用纯 C 语言编写的库,有 Python 2 和 Python 3 的绑定。Yum 不使用单独的库来执行这些功能
18DNF 包含 29000 行代码Yum 包含 56000 行代码
19DNF 由 Ales Kozumplik 开发YUM 由 Zdenek Pavlas、Jan Silhan 和团队成员开发

via: https://www.2daygeek.com/comparison-difference-between-dnf-vs-yum/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

为服务器打补丁是 Linux 系统管理员的一项重要任务,为的是让系统更加稳定,性能更加优化。厂商经常会发布一些安全/高危的补丁包,相关软件需要升级以防范潜在的安全风险。

Yum (Yellowdog Update Modified) 是 CentOS 和 RedHat 系统上用的 RPM 包管理工具,yum history 命令允许系统管理员将系统回滚到上一个状态,但由于某些限制,回滚不是在所有情况下都能成功,有时 yum 命令可能什么都不做,有时可能会删掉一些其他的包。

我建议你在升级之前还是要做一个完整的系统备份,而 yum history 并不能用来替代系统备份的。系统备份能让你将系统还原到任意时候的节点状态。

推荐阅读:

某些情况下,安装的应用程序在升级了补丁之后不能正常工作或者出现一些错误(可能是由于库不兼容或者软件包升级导致的),那该怎么办呢?

与应用开发团队沟通,并找出导致库和软件包的问题所在,然后使用 yum history 命令进行回滚。

注意:

  • 它不支持回滚 selinux,selinux-policy-*,kernel,glibc (以及依赖 glibc 的包,比如 gcc)。
  • 不建议将系统降级到更低的版本(比如 CentOS 6.9 降到 CentOS 6.8),这会导致系统处于不稳定的状态

让我们先来看看系统上有哪些包可以升级,然后挑选出一些包来做实验。

# yum update
Loaded plugins: fastestmirror, security
Setting up Update Process
Loading mirror speeds from cached hostfile
epel/metalink | 12 kB 00:00
 * epel: mirror.csclub.uwaterloo.ca
base | 3.7 kB 00:00
dockerrepo | 2.9 kB 00:00
draios | 2.9 kB 00:00
draios/primary_db | 13 kB 00:00
epel | 4.3 kB 00:00
epel/primary_db | 5.9 MB 00:00
extras | 3.4 kB 00:00
updates | 3.4 kB 00:00
updates/primary_db | 2.5 MB 00:00
Resolving Dependencies
--> Running transaction check
---> Package git.x86_64 0:1.7.1-8.el6 will be updated
---> Package git.x86_64 0:1.7.1-9.el6_9 will be an update
---> Package httpd.x86_64 0:2.2.15-60.el6.centos.4 will be updated
---> Package httpd.x86_64 0:2.2.15-60.el6.centos.5 will be an update
---> Package httpd-tools.x86_64 0:2.2.15-60.el6.centos.4 will be updated
---> Package httpd-tools.x86_64 0:2.2.15-60.el6.centos.5 will be an update
---> Package perl-Git.noarch 0:1.7.1-8.el6 will be updated
---> Package perl-Git.noarch 0:1.7.1-9.el6_9 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================
 Package Arch Version Repository Size
=================================================================================================
Updating:
 git x86_64 1.7.1-9.el6_9 updates 4.6 M
 httpd x86_64 2.2.15-60.el6.centos.5 updates 836 k
 httpd-tools x86_64 2.2.15-60.el6.centos.5 updates 80 k
 perl-Git noarch 1.7.1-9.el6_9 updates 29 k

Transaction Summary
=================================================================================================
Upgrade 4 Package(s)

Total download size: 5.5 M
Is this ok [y/N]: n

你会发现 git 包可以被升级,那我们就用它来实验吧。运行下面命令获得软件包的版本信息(当前安装的版本和可以升级的版本)。

# yum list git
Loaded plugins: fastestmirror, security
Setting up Update Process
Loading mirror speeds from cached hostfile
 * epel: mirror.csclub.uwaterloo.ca
Installed Packages
git.x86_64 1.7.1-8.el6 @base
Available Packages
git.x86_64 1.7.1-9.el6_9 updates

运行下面命令来将 git1.7.1-8 升级到 1.7.1-9

# yum update git
Loaded plugins: fastestmirror, presto
Setting up Update Process
Loading mirror speeds from cached hostfile
 * base: repos.lax.quadranet.com
 * epel: fedora.mirrors.pair.com
 * extras: mirrors.seas.harvard.edu
 * updates: mirror.sesp.northwestern.edu
Resolving Dependencies
--> Running transaction check
---> Package git.x86_64 0:1.7.1-8.el6 will be updated
--> Processing Dependency: git = 1.7.1-8.el6 for package: perl-Git-1.7.1-8.el6.noarch
---> Package git.x86_64 0:1.7.1-9.el6_9 will be an update
--> Running transaction check
---> Package perl-Git.noarch 0:1.7.1-8.el6 will be updated
---> Package perl-Git.noarch 0:1.7.1-9.el6_9 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================
 Package Arch Version Repository Size
=================================================================================================
Updating:
 git x86_64 1.7.1-9.el6_9 updates 4.6 M
Updating for dependencies:
 perl-Git noarch 1.7.1-9.el6_9 updates 29 k

Transaction Summary
=================================================================================================
Upgrade 2 Package(s)

Total download size: 4.6 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 4.6 M
(1/2): git-1.7.1-9.el6_9.x86_64.rpm | 4.6 MB 00:00
(2/2): perl-Git-1.7.1-9.el6_9.noarch.rpm | 29 kB 00:00
-------------------------------------------------------------------------------------------------
Total 5.8 MB/s | 4.6 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
 Updating : perl-Git-1.7.1-9.el6_9.noarch 1/4
 Updating : git-1.7.1-9.el6_9.x86_64 2/4
 Cleanup : perl-Git-1.7.1-8.el6.noarch 3/4
 Cleanup : git-1.7.1-8.el6.x86_64 4/4
 Verifying : git-1.7.1-9.el6_9.x86_64 1/4
 Verifying : perl-Git-1.7.1-9.el6_9.noarch 2/4
 Verifying : git-1.7.1-8.el6.x86_64 3/4
 Verifying : perl-Git-1.7.1-8.el6.noarch 4/4

Updated:
 git.x86_64 0:1.7.1-9.el6_9

Dependency Updated:
 perl-Git.noarch 0:1.7.1-9.el6_9

Complete!

验证升级后的 git 版本.

# yum list git
Installed Packages
git.x86_64 1.7.1-9.el6_9 @updates

或
# rpm -q git
git-1.7.1-9.el6_9.x86_64

现在我们成功升级这个软件包,可以对它进行回滚了。步骤如下。

使用 YUM history 命令回滚升级操作

首先,使用下面命令获取 yum 操作的 id。下面的输出很清晰地列出了所有需要的信息,例如操作 id、谁做的这个操作(用户名)、操作日期和时间、操作的动作(安装还是升级)、操作影响的包数量。

# yum history
或
# yum history list all
Loaded plugins: fastestmirror, presto
ID | Login user | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
 13 | root | 2017-08-18 13:30 | Update | 2
 12 | root | 2017-08-10 07:46 | Install | 1
 11 | root | 2017-07-28 17:10 | E, I, U | 28 EE
 10 | root | 2017-04-21 09:16 | E, I, U | 162 EE
 9 | root | 2017-02-09 17:09 | E, I, U | 20 EE
 8 | root | 2017-02-02 10:45 | Install | 1
 7 | root | 2016-12-15 06:48 | Update | 1
 6 | root | 2016-12-15 06:43 | Install | 1
 5 | root | 2016-12-02 10:28 | E, I, U | 23 EE
 4 | root | 2016-10-28 05:37 | E, I, U | 13 EE
 3 | root | 2016-10-18 12:53 | Install | 1
 2 | root | 2016-09-30 10:28 | E, I, U | 31 EE
 1 | root | 2016-07-26 11:40 | E, I, U | 160 EE

上面命令显示有两个包受到了影响,因为 git 还升级了它的依赖包 perl-Git。 运行下面命令来查看关于操作的详细信息。

# yum history info 13
Loaded plugins: fastestmirror, presto
Transaction ID : 13
Begin time : Fri Aug 18 13:30:52 2017
Begin rpmdb : 420:f5c5f9184f44cf317de64d3a35199e894ad71188
End time : 13:30:54 2017 (2 seconds)
End rpmdb : 420:d04a95c25d4526ef87598f0dcaec66d3f99b98d4
User : root
Return-Code : Success
Command Line : update git
Transaction performed with:
 Installed rpm-4.8.0-55.el6.x86_64 @base
 Installed yum-3.2.29-81.el6.centos.noarch @base
 Installed yum-plugin-fastestmirror-1.1.30-40.el6.noarch @base
 Installed yum-presto-0.6.2-1.el6.noarch @anaconda-CentOS-201207061011.x86_64/6.3
Packages Altered:
 Updated git-1.7.1-8.el6.x86_64 @base
 Update 1.7.1-9.el6_9.x86_64 @updates
 Updated perl-Git-1.7.1-8.el6.noarch @base
 Update 1.7.1-9.el6_9.noarch @updates
history info

运行下面命令来回滚 git 包到上一个版本。

# yum history undo 13
Loaded plugins: fastestmirror, presto
Undoing transaction 53, from Fri Aug 18 13:30:52 2017
 Updated git-1.7.1-8.el6.x86_64 @base
 Update 1.7.1-9.el6_9.x86_64 @updates
 Updated perl-Git-1.7.1-8.el6.noarch @base
 Update 1.7.1-9.el6_9.noarch @updates
Loading mirror speeds from cached hostfile
 * base: repos.lax.quadranet.com
 * epel: fedora.mirrors.pair.com
 * extras: repo1.dal.innoscale.net
 * updates: mirror.vtti.vt.edu
Resolving Dependencies
--> Running transaction check
---> Package git.x86_64 0:1.7.1-8.el6 will be a downgrade
---> Package git.x86_64 0:1.7.1-9.el6_9 will be erased
---> Package perl-Git.noarch 0:1.7.1-8.el6 will be a downgrade
---> Package perl-Git.noarch 0:1.7.1-9.el6_9 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================
 Package Arch Version Repository Size
=================================================================================================
Downgrading:
 git x86_64 1.7.1-8.el6 base 4.6 M
 perl-Git noarch 1.7.1-8.el6 base 29 k

Transaction Summary
=================================================================================================
Downgrade 2 Package(s)

Total download size: 4.6 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 4.6 M
(1/2): git-1.7.1-8.el6.x86_64.rpm | 4.6 MB 00:00
(2/2): perl-Git-1.7.1-8.el6.noarch.rpm | 29 kB 00:00
-------------------------------------------------------------------------------------------------
Total 3.4 MB/s | 4.6 MB 00:01
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
 Installing : perl-Git-1.7.1-8.el6.noarch 1/4
 Installing : git-1.7.1-8.el6.x86_64 2/4
 Cleanup : perl-Git-1.7.1-9.el6_9.noarch 3/4
 Cleanup : git-1.7.1-9.el6_9.x86_64 4/4
 Verifying : git-1.7.1-8.el6.x86_64 1/4
 Verifying : perl-Git-1.7.1-8.el6.noarch 2/4
 Verifying : git-1.7.1-9.el6_9.x86_64 3/4
 Verifying : perl-Git-1.7.1-9.el6_9.noarch 4/4

Removed:
 git.x86_64 0:1.7.1-9.el6_9 perl-Git.noarch 0:1.7.1-9.el6_9

Installed:
 git.x86_64 0:1.7.1-8.el6 perl-Git.noarch 0:1.7.1-8.el6

Complete!

回滚后,使用下面命令来检查降级包的版本。

# yum list git
或
# rpm -q git
git-1.7.1-8.el6.x86_64

使用YUM downgrade 命令回滚升级

此外,我们也可以使用 YUM downgrade 命令回滚升级。

# yum downgrade git-1.7.1-8.el6 perl-Git-1.7.1-8.el6
Loaded plugins: search-disabled-repos, security, ulninfo
Setting up Downgrade Process
Resolving Dependencies
--> Running transaction check
---> Package git.x86_64 0:1.7.1-8.el6 will be a downgrade
---> Package git.x86_64 0:1.7.1-9.el6_9 will be erased
---> Package perl-Git.noarch 0:1.7.1-8.el6 will be a downgrade
---> Package perl-Git.noarch 0:1.7.1-9.el6_9 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================
 Package Arch Version Repository Size
=================================================================================================
Downgrading:
 git x86_64 1.7.1-8.el6 base 4.6 M
 perl-Git noarch 1.7.1-8.el6 base 29 k

Transaction Summary
=================================================================================================
Downgrade 2 Package(s)

Total download size: 4.6 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): git-1.7.1-8.el6.x86_64.rpm | 4.6 MB 00:00
(2/2): perl-Git-1.7.1-8.el6.noarch.rpm | 28 kB 00:00
-------------------------------------------------------------------------------------------------
Total 3.7 MB/s | 4.6 MB 00:01
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
 Installing : perl-Git-1.7.1-8.el6.noarch 1/4
 Installing : git-1.7.1-8.el6.x86_64 2/4
 Cleanup : perl-Git-1.7.1-9.el6_9.noarch 3/4
 Cleanup : git-1.7.1-9.el6_9.x86_64 4/4
 Verifying : git-1.7.1-8.el6.x86_64 1/4
 Verifying : perl-Git-1.7.1-8.el6.noarch 2/4
 Verifying : git-1.7.1-9.el6_9.x86_64 3/4
 Verifying : perl-Git-1.7.1-9.el6_9.noarch 4/4

Removed:
 git.x86_64 0:1.7.1-9.el6_9 perl-Git.noarch 0:1.7.1-9.el6_9

Installed:
 git.x86_64 0:1.7.1-8.el6 perl-Git.noarch 0:1.7.1-8.el6

Complete!

注意: 你也需要降级依赖包,否则它会删掉当前版本的依赖包而不是对依赖包做降级,因为 downgrade 命令无法处理依赖关系。

至于 Fedora 用户

命令是一样的,只需要将包管理器名称从 yum 改成 dnf 就行了。

# dnf list git
# dnf history
# dnf history info
# dnf history undo
# dnf list git
# dnf downgrade git-1.7.1-8.el6 perl-Git-1.7.1-8.el6

via: https://www.2daygeek.com/rollback-fallback-updates-downgrade-packages-centos-rhel-fedora/

作者:2daygeek 译者:lujun9972 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

随着 DNF 软件包管理器在最近的 Fedora 版本里面工作日益工作良好,我们可以预见到 Yum 将在之后的 Fedora 版本中谢幕。

当然,Yum 还一直广泛用在 RHEL 7 中,而在 Fedora 这边,估计在大约一年后的 Fedora 28 乃至 29 中正式退休。

在 Fedora 开发者邮件列表中有一个讨论 Yum 退休的新话题。看起来在 Fedora 28 或 29 的时候会移除 Yum。DNF 已经提供了与 Yum 一样的能力。Fedora 也在开发一个“富依赖”的支持,而这个功能 Yum 不支持,所以这也表明了 Yum 将在以后的 Fedora 系统中消失。

邮件列表中也提到了 Yum 和 DNF 还存在一些差异需要解决,但是看起来在 2018 年应该可以看到希望。