从源代码构建可以获得已配置仓库中没有的版本或功能，但这会把集成、更新和信任工作从发行版转移给你。如果受支持的发行版软件包能够满足需求，应优先使用它。
软件包 · 第 7 课
编译源代码
学习如何验证、配置、构建、测试、暂存并跟踪从源代码编译的软件。
构建前验证并阅读
从经过身份验证的上游发布渠道获取源代码，通过受信任路径验证签名或校验和；然后先检查归档，再把它提取到非特权暂存目录。阅读 README、INSTALL、SECURITY 和项目构建文档等文件。
构建说明也是可执行代码。configure 脚本、构建定义、测试或编译器插件都可能以你的用户身份运行任意命令。不要构建不受信任的源代码，也不要用 sudo 运行构建本身。
为什么编译步骤通常不应该使用 sudo？
安装构建要求
在 Debian 家族开发系统上，常见起点是：
$ sudo apt install build-essential
这会安装一组基础编译器和构建工具，而不是每个项目所需的全部依赖。项目还可能需要语言运行时、生成器、构建系统工具、开发头文件或精确的库版本。应从受信任仓库安装要求，并区分构建依赖与运行时依赖。
build-essential 在 Debian 家族系统上提供什么？
配置与构建
传统的 Autoconf 风格项目可能使用：
$ ./configure --prefix=/usr/local
$ make
configure 检查环境，并根据所选选项生成构建文件。make 读取通常位于 Makefile 中的依赖与命令规则，创建请求的目标。
这一顺序并不通用。项目可能使用 CMake、Meson、Ninja、语言专用工具或自定义脚本。应遵循准确版本的文档，不要仅仅因为熟悉就运行 ./configure。如果构建系统支持，源代码树外的构建目录可以让生成文件保持分离。
在传统流程中，make 做什么？
安装前测试
运行项目文档指定的测试目标，例如：
$ make check
实际目标可能是 test、check 或一个独立命令。测试失败时应调查原因，而不是安装未经测试的输出。测试可能要求网络访问、服务、特殊硬件或隔离环境；执行前应像审查其他构建代码一样审查测试。
文档指定的测试套件失败时，应该怎么做？
暂存并跟踪安装
sudo make install 可能直接把文件复制到系统前缀，却不记录到原生软件包数据库。卸载目标是可选的，可能并不完整；后续升级也可能覆盖文件或留下孤立文件。
应优先选择以下受控方法之一：
- 使用发行版打包工具构建正式原生软件包
- 在策略允许时安装到
/usr/local等明确分离的前缀 - 使用
DESTDIR等受支持机制把文件暂存到临时打包根目录 - 适当时使用非特权用户前缀、隔离环境或容器
checkinstall 可以为某些 make install 流程创建简单软件包，但并不通用，也无法替代经过审核的发行版质量打包配方。绝不能把它当作“始终使用”的规则。进行任何特权复制前，应检查暂存文件列表、所有权、权限、路径，以及卸载或升级计划。
受支持的 DESTDIR 暂存安装有什么用途？
可以在可丢弃环境中通过在 Linux 中从源代码构建软件实验练习这一流程，避免把实验文件混入生产系统。
课程已完成
你已完成 编译源代码
现在，你可以把源代码构建作为受控的软件供应流程来处理。
验证源代码身份，并把其说明当作可执行代码审查。
从受信任仓库安装明确的构建要求。
在没有不必要权限的情况下配置、构建和测试。
写入系统前暂存并检查输出。
使用原生打包或有意识选择的隔离前缀跟踪已安装文件。