软件包管理

复习定位

Linux应用软件的安装和更新不像Windows那样去官网下载安装包——而是通过包管理器统一管理。Debian系的apt、RedHat系的dnf以及通用的源码编译是安装软件的三种主要方式。包管理器自动解决依赖关系——确保安装一个软件时所需的库也都已安装。

Debian系：dpkg与apt

dpkg——Debian包管理的底层工具——直接对.deb包进行安装和卸载。dpkg -i package.deb安装、dpkg -r package卸载(保留配置文件)、dpkg -P package完全清除(包括配置文件)。dpkg不会自动处理依赖——缺失的依赖必须另行手动安装。所以日常不使用dpkg直接操作——而是使用自动解决依赖的上层工具。

APT(Advanced Package Tool)——在dpkg之上自动解析依赖并管理仓库。apt update从软件源更新本地包索引。apt upgrade升级所有可升级的包。apt install安装指定包+所有依赖——避免了逐个解析依赖的繁琐。

软件源在/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的.list文件中定义——每个源是一个URL+分发名+组件(如 deb http://archive.ubuntu.com/ubuntu jammy main universe)。AP还集成GPG密钥验证——确保包在传输过程中未被篡改——通过信任发布者的公钥来验证仓库Release文件的签名。

RedHat系：rpm与dnf

rpm——RedHat包管理器——直接操作.rpm包。rpm -ivh安装、rpm -e卸载。rpm与dpkg是平级工具——同样不处理依赖。

dnf(替代旧yum)——YUM的现代继承者——自动处理依赖。dnf install/uninstall/update。配置文件在/etc/yum.repos.d/。

rpm和deb包格式不能混用——所以Ubuntu不能直接用.rpm文件(没有转换工具直接装——需要用alien工具convert)。不同发行版的包管理差异是Linux生态碎片化的重要表现。

源码编译安装

标准三步：./configure && make && make install。

configure——检测环境——检查编译器和依赖库是否存在——生成符合本机环境的Makefile。可指定安装路径如--prefix=/usr/local。

make——运行编译——调用gcc和ld将源代码编译为二进制。

make install——将编译好的程序、库和配置文件复制到系统目录。

源码编译的最大好处：可以自定义编译选项(开启/关闭特定功能)、指定安装位置、优化指令集。但卸载复杂——make uninstall不一定存在于每个项目中——而且不会计入包管理器的数据库中——之后包管理器升级/卸载时会出差。推荐用checkinstall打包成deb/rpm再安装以保持兼容。

复习检查

1. dpkg无法自动安装依赖——那么日常使用apt是为了什么——apt和dpkg各自的角色区别是抽象还是底层？

2. 软件源在加载时需要导入发布者公钥——apt-key add(新版本使用signed-by放在sources.list中直接引用gpg文件)——GPG验证如何确保包的完整性？

3. 源码编译安装的make install通常需要root权限——如果不用root安装到--prefix=$HOME/local——对全局系统有什么影响——如何配置环境变量使其在shell中可执行。

4. .deb和.rpm文件格式互不兼容——有没有方式在一台机器上同时使用两种包格式(并不推荐——/usr目录结构可能冲突)？

5. apt upgrade和apt dist-upgrade有什么区别——dist-upgrade在必要时可能会删除一些旧包、安装新依赖以处理版本冲突——与普通upgrade不同的行为在什么场景下发挥作用？

dpkg与apt的分工关系详解

dpkg是底层工具——直接操作.deb包文件：安装、卸载、查询已安装包的信息。但dpkg不会自动处理依赖——如果你用dpkg -i pkgA.deb安装一个依赖pkgB的包——而pkgB尚未安装——dpkg报错并停止。

APT是高级工具——在dpkg之上工作——负责从软件源获取包信息、解析依赖关系、依次下载所需的包——最终调用dpkg执行安装。APT的解耦设计使其能够从多个软件源(main/universe/multiverse)自动组合不同包版本以满足复杂的依赖。

apt-cache policy <package>可以看到包来自哪个源的哪个版本——以及该包各版本的优先级。apt-cache show <package>显示包的详细信息(版本/描述/依赖/冲突等)。

apt update与apt upgrade的区别

apt update: 从软件源下载最新的包索引列表(而不是更新系统)——更新本地的版本信息
apt upgrade: 在apt update之后——检查本地已安装的包——升级所有可以升级的包
             (不安装/删除新包、不处理复杂的依赖变更)
apt dist-upgrade: 必要时允许安装新包或删除冲突包以完成依赖变更
                  (处理需要替换的依赖库升级)

一般情况下先用apt update获取最新索引——再用apt upgrade或apt dist-upgrade执行升级。在major release版本升级(如Ubuntu 22.04→24.04)时——apt dist-upgrade更加常见——因为基础库的版本变更可能涉及较大的依赖变更。

软件源配置和GPG验证的工作原理

APT将软件源定义在/etc/apt/sources.list和/etc/apt/sources.list.d/目录下。每个源对应的服务器上发布一个Release文件——会被GPG签名——APT下载Release.gpg或InRelease文件——使用导入的GPG公钥验证签名的合法性——确保Release文件未被篡改。验证通过后再从Release文件中查看哪些Packages.gz(包索引)或Contents-arch文件可用——下载实际包列表。

GPG验证阻止了中间人攻击篡改软件源内容——传统的气象中的传输加密协助维护了包传输的安全通道。在信任仓库发布公钥时需要使用signed-by命令明确的用于加签方的公钥路径——以防止签名与公钥之间产生混淆。

快照与版本锁定

APT支持将包的版本固定到特定版本——防止意外升级导致依赖破坏：

apt-mark hold <package>   # 保持指定包在当前版本——跳过升级
apt-mark showhold         # 显示所有被保持的包

这在生产环境中非常有用——基础组件(如Docker、数据库)的升级需要在测试环境中充分验证后才能推送到生产环境——使用apt-mark hold锁定版本——在验证完成后再unhold。

源码编译安装的详细步骤与依赖检查

./configure阶段——如果在系统中没有找到所依赖的库——configure脚本会报错并退出。常见的问题：配置时缺少依赖如没有安装libssl-dev——编译Nginx的HTTPS模块必须依赖OpenSSL开发包——configure会检查ssl.h是否存在——不存在则禁用HTTPS功能或直接终止。通过输出configure: error:的内容即可知道缺失哪个开发包(apt install libssl-dev即可解决)。

已经编译好后如果需要卸载——如果原程序没有提供make uninstall——最可靠的办法是保留当时的configure日志和install_manifest.txt(被写入make install的文件列表)——通过逐项删除。或者在编译阶段使用checkinstall取代make install生成.deb包——用包管理器安装和卸载。

复习检查（续）

6. apt update和apt upgrade的执行顺序——必须先apt update再apt upgrade——因为update从软件源更新本地包索引——upgrade根据最新索引判断哪些包可升级。

7. apt-mark hold的作用——将包固定在当前版本——apt upgrade和apt dist-upgrade都不会更改该版本——常用于DB/容器运行时等关键组件的版本管理。

8. configure阶段缺失依赖的处理方法——查看configure: error:信息确定缺失的库名——使用apt-cache search <关键词>找到对应的-dev包——安装后重新执行configure。

9. .deb包格式和.rpm包格式不兼容的根因——两种格式使用完全不同的元数据格式和数据压缩方式——dpkg不认识rpm、rpm也不认识deb——alien工具可以在两者间转换但结果不一定完美。

10. make install默认将程序安装在/usr/local/下——而包管理器管理的程序安装在/usr/下——两者都能在PATH系统环境变量中找到——但/usr/local的优先度取决于PATH的目录顺序。

软件包管理的生态差异

Debian系(apt)和RedHat系(dnf)两种包管理生态的差异不仅体现在包格式和命令上——也体现在社区质量和仓库策略上：

• Debian的"main"仓库只包含符合Debian自由软件指南(DFSG)的完全自由软件——"non-free"仓库包含非自由固件和驱动——contrib是依赖非自由软件的自由软件仓库
• RedHat/CentOS的BaseOS和AppStream仓库——通过模块化流(module stream)支持在同一OS版本中安装同一软件的不同版本(如PostgreSQL 13/14/15可以选择)

包管理器的安全更新机制

Debian系使用unattended-upgrades自动安装安全更新包——关键配置为Unattended-Upgrade::Allowed-Origins:: "${distro_id}:${distro_codename}-security"——只更新源自安全仓库的包——不更新普通仓库中的功能版本。自动更新和系统重启策略很重要——尤其对于云中机器——建议配置自动重启时间窗口。

DPkg日志管理

/var/log/dpkg.log记录了dpkg的所有操作——安装/卸载/升级的时间、包名、版本号。/var/log/apt/history.log记录apt执行的事务日志——安装/删除的包名列表和原因。这些日志在排障——特别是系统升级失败或多用户管理机器中谁在什么时间做了软件变更——是非常有用的审计来源。

Snaps和Flatpak——容器化的包管理

除了传统的dpkg/rpm和apt/dnf——Linux还发展了Snap(Canonical主推)和Flatpak(RedHat主推)等容器化的包管理方案——它们将应用及其所有依赖打包为一个镜像——与系统其他部分隔离。优点：解决依赖冲突——应用发布者直接交付(不经过发行版仓库筛选)——自动更新(Backend-controlled updates)。缺点：占用更多的磁盘空间——启动延迟比本地应用更长——在某些桌面环境中的系统托盘集成弱于传统打包。

Snap的安装与使用

snap install <package>           # 安装应用
snap install --classic <package> # 允许访问系统全文件(如IDE等需要完整访问)
snap list                       # 列出安装的snap包
snap refresh                    # 更新所有snap应用

Snap包的安装目录在/snap/下——每个Snap应用被Mount到一个只读的squashfs文件系统镜像中——保障了应用文件在运行时不会被意外修改——同时限制了应用的读写访问范围。这是一种安全性方面的深度优化——但也带来了文件管理上的不便（不能像传统安装那样在文件管理器中随意浏览二进制路径）。

复习检查（续二）

11. unattended-upgrades的配置要点——Allowed-Origins指定允许的来源——通常只开启${distro_id}:${distro_codename}-security——只自动安装安全更新——不升级普通功能版本。

12. dpkg的日志文件/var/log/dpkg.log的内容示例——记录了每次操作的包名、版本变更和时间——如2024-01-01 10:00:00 install openssh-server 1:8.9p1-3。

13. Snap包与系统其他部分的隔离方式——Snap使用squashfs只读挂载——限制应用的写操作仅限于其数据目录——不影响到系统其他部分——降低了安全隐患的传播范围。

14. Debian的main/non-free/contrib仓库划分的含义——main包含完全自由的软件(符合DFSG准则)——non-free包含不自由的软件(如专有驱动和固件)——contrib是本身自由但依赖于非自由组件的软件。

15. RedHat的模块化流(module stream)的作用——在同一个操作系统版本上——可以通过模块流选择不同版本的应用软件——如PostgreSQL 14、15和16可以在同一最小平台配置上供不同的业务模块选择。

包管理器的依赖关系管理算法

APT在安装新包时——通过回溯（backtracking）算法解决复杂的依赖关系。假定要安装A包时——APT检查A的依赖——收集所有需要的包——按依赖关系排序——确认不产生冲突(如A需要B≥2.0但C需要B≤1.9——就是冲突——APT可以尝试选择不同版本的A或C或在有些发行版不是通过系统包的仓库保证不会有这种冲突)。APT使用一种贪心算法处理典型的依赖——并默认配置在检测到"broken packages"时不进行不安全的自动降级操作——而是提示用户手动修复。

从源码安装时的常见依赖检查方式

如果系统没有提供二进制包——需要从源码编译安装时——可能需要手动检查依赖——没有configure自动检测时依赖性判断更耗时。此时可以：

# 查看程序文档中(README/INSTALL)列出的构建依赖
# 使用发行版包管理器的搜索工具查找需要的开发包
apt-cache search <name>-dev

# 检查二进制系统中所需的头文件和库是否已安装
ls /usr/include/<header>.h
ldconfig -p | grep <library>

# 使用pkg-config工具检查库发行和编译参数
pkg-config --libs --cflags <library>

复习检查（续三）

16. pkg-config工具的作用——在编译源码时提供库的编译参数(头文件路径、库链接路径)——简化了configure脚本或Makefile中库引用的配置。

17. APT的回溯(backtracking)算法——在遇到依赖冲突时尝试降级或选择其他版本来满足依赖链——如果仍然无法满足全部依赖——报告并让用户在提示下手动操作。

18. 源码编译安装时的典型依赖问题——configure找不到libssl-dev导致HTTPS模块被禁用——apt install libssl-dev解决后——需要重新configure才能启用。

19. 包管理系统中的"虚拟包"概念——Debian中的default-mysql-server等虚拟包——本身不是一个具体包——而是指向具体实现(如mariadb-server-10.6或mysql-server-8.0)——允许系统在满足接口依赖时从多个实现中选择。

20. checkinstall将源码安装转为deb包的原理——监控make install的文件操作——记录安装的文件——生成一个deb包的postinst、prerm等维护脚本——打包成一个标准的.deb文件——使源码安装可以被apt/dpkg管理。

不同包管理器的优缺点横向对比

APT(dpk): 
  优点: 依赖解析强——包最多——自动更新的用户群广泛
  缺点: 升级大版本发布时跨版本(do-release-upgrade)稍复杂
DNF(rpm):
  优点: 模块化流功能灵活——自动化管理依赖链升级系统能力强
  缺点: 包的绝对数量略少于Debian——非官方源(EPEL)配置额外步骤
Snap:
  优点: 跨发行版——自动更新——应用沙箱隔离
  缺点: 启动慢——磁盘空间多——在某些场景下更新不能按需控制
Flatpak:
  优点: 沙箱化、成熟的桌面应用管理——runtime共享减少空间浪费
  缺点: 主要面向桌面图形应用——命令行和服务器领域的支持还不足

选择合适的包管理方式取决于具体的部署场景——Linux服务器管理中以apt/dnf为核心——桌面用户会额外使用Snap或Flatpak获得更多桌面应用。

复习检查（续四）