第1章：rootfs中的包管理机制

说到rootfs的构建，包管理工具是绕不开的话题。我这些年折腾过不少嵌入式系统，从OpenWrt到Yocto，从Debian到Buildroot，每种方案背后都离不开包管理这个核心机制。说白了，包管理就是解决「软件怎么装、怎么删、怎么解决依赖」的问题。

1.1 包管理工具的本质

包管理工具干的事情，其实就三件：

• 安装：把软件包解压到正确位置
• 依赖解析：确保所有需要的库都装好了
• 卸载：干净地删除文件，不留下垃圾

你想想看，如果没有包管理，手动装个软件得有多痛苦。我记得早期做嵌入式开发时，经常遇到「装A需要B，装B需要C，装C又需要A」这种循环依赖，手动折腾一整天都是常事。

1.2 apt/dpkg：Debian系的王牌

apt和dpkg是Debian/Ubuntu系统的标配。它们的关系很简单：dpkg是底层工具，apt是上层封装。

dpkg直接操作.deb包，负责安装、卸载、查询。但它不处理依赖——你装一个包，它不会自动去下载依赖。这就是apt存在的意义。

apt会维护一个软件源列表（/etc/apt/sources.list），当你执行apt install时，它会：

1. 从软件源下载包信息
2. 解析依赖树
3. 按顺序下载所有需要的包
4. 调用dpkg逐个安装

我在项目中遇到过一个问题：用dpkg强制安装一个包，结果系统库版本被覆盖，导致ssh都连不上了。从那以后，我养成了一个习惯——能用apt就别用dpkg，除非你非常清楚自己在干什么。

1.3 rpm/yum：Red Hat系的方案

rpm是Red Hat系的底层工具，相当于dpkg。yum（现在更多用dnf）是上层封装，相当于apt。

rpm包的后缀是.rpm，它同样不处理依赖。yum/dnf会从仓库下载元数据，解析依赖，然后调用rpm安装。

这里有个有意思的区别：rpm支持「事务性」操作。什么意思？就是一组操作要么全部成功，要么全部回滚。我在做企业级嵌入式系统时，这个特性帮了大忙——升级固件时如果中途断电，系统不会变成半残废状态。

特性	dpkg	rpm
包格式	.deb	.rpm
依赖处理	不处理	不处理
事务支持	有限	原生支持
上层工具	apt/apt-get	yum/dnf

1.4 opkg：嵌入式系统的轻量级选择

opkg是专门为嵌入式Linux设计的包管理工具。它借鉴了dpkg/apt的设计思路，但做了大量精简。

为什么需要opkg？因为apt和yum太「重」了。它们需要Python、需要数据库、需要大量内存。在只有32MB Flash、64MB RAM的嵌入式设备上，根本跑不动。

opkg的特点：

• 体积小：二进制文件只有几百KB
• 依赖少：只需要基本的C库
• 支持离线安装：可以预下载.ipk包，然后离线安装
• 支持软件源：和apt一样，可以从远程仓库下载

1.5 包管理在rootfs中的角色

在rootfs构建中，包管理工具扮演着三个角色：

1. 构建时的依赖管理：构建rootfs时，需要安装基础包、库、工具链。包管理工具确保这些组件版本匹配。
2. 运行时的软件管理：设备部署后，用户可能需要安装新软件或更新旧软件。包管理工具提供标准化的操作接口。
3. 系统维护：包括安全更新、漏洞修复、配置管理等。

我个人习惯在构建rootfs时，尽量使用目标系统的包管理工具。比如构建Debian系的rootfs，就用debootstrap+apt；构建OpenWrt的rootfs，就用opkg。这样能保证构建环境和运行环境的一致性。

1.6 包依赖冲突的根源

依赖冲突说白了就是「版本打架」。常见的场景有：

• 包A需要libfoo >= 2.0，但包B需要libfoo <= 1.8
• 两个不同的包提供了同一个文件
• 升级一个库，导致依赖它的旧应用无法运行

包管理工具通过「依赖图」来解决这个问题。每个包都声明自己的依赖和冲突，工具会计算出一个可行的安装方案。如果找不到方案，就会报错。

我遇到过最头疼的情况是：一个第三方库只提供了.so文件，没有打包成.deb或.rpm。结果手动安装后，apt完全不知道它的存在，后续安装其他包时，apt以为这个库不存在，又装了一个不同版本——冲突就来了。

所以，尽量用包管理工具管理所有软件，不要手动往系统里塞文件。这是避免依赖冲突的第一原则。

1.7 知识体系总览

下面这张图展示了包管理工具在rootfs中的整体架构：

这张图把包管理工具、核心功能、在rootfs中的角色串起来了。你可以看到，无论哪种工具，最终都要解决「安装、依赖、版本、源」这四个问题。而它们在rootfs中的角色，贯穿了从构建到运行再到维护的全生命周期。

可可精品资料库