第28章打包发布

课程目录第28章打包发布

第28章：打包发布——从代码到可交付的最后一公里

说实话，很多C语言开发者写代码时意气风发，一到打包发布就抓瞎。我见过太多人把二进制文件往用户面前一丢，说「你拿去跑吧」。结果呢？用户缺库、版本不对、系统不兼容……各种问题炸成一锅粥。

这一章，我们就来聊聊怎么体面地把你的命令行工具交付出去。说白了，就是让用户拿到手就能用，不用折腾环境。

28.1 为什么需要打包？

你想想看，你的工具依赖了多少东西？glibc、libcurl、libssl……用户机器上不一定都有。就算有，版本也可能对不上。

我早期做过一个日志分析工具，自己机器上跑得飞起。发给同事，他那边直接段错误。查了半天，是他系统里的glibc版本太老。从那以后，我再也不敢裸发二进制了。

打包要解决的核心问题就三个：

依赖管理：确保用户机器上有正确的运行时库
安装路径：把文件放到系统该放的位置
卸载干净：用户不想要了，能一键清除

28.2 静态编译——最省心的方式

静态编译是我个人最推荐的方式。说白了，就是把所有依赖库都揉进一个二进制文件里。用户拿到手，chmod +x 就能跑。

静态编译的好处：

零依赖，用户不需要装任何东西
跨发行版兼容，Ubuntu、CentOS、Debian通吃
部署简单，一个文件搞定

怎么做？以gcc为例：

# 静态编译示例
gcc -static -o mytool main.c -lm -lpthread

# 验证是否静态链接
file mytool
# 输出应该包含 "statically linked"

嗯，这里要注意：静态编译会让二进制体积变大。我有个工具，动态链接时只有200KB，静态编译后飙到2MB。但说实话，现在硬盘和带宽都不值钱，这点代价完全可以接受。

注意：有些库（比如glibc的nss模块）不支持完全静态编译。如果你遇到「getaddrinfo」之类的函数调用失败，可能需要用 musl 工具链替代 glibc。

28.3 deb包制作——Debian/Ubuntu系

如果你面向的是Debian或Ubuntu用户，deb包是标准答案。我习惯用 dpkg-deb 手动打包，虽然也有dh_make这类自动化工具，但手动打包能让你理解每一块在干什么。

一个deb包的核心结构是这样的：

mytool-1.0.0/
├── DEBIAN/
│   └── control          # 包元信息
└── usr/
    ├── bin/
    │   └── mytool       # 你的二进制
    └── share/
        └── man/
            └── man1/
                └── mytool.1.gz  # 帮助文档

control 文件长这样：

Package: mytool
Version: 1.0.0
Section: utils
Priority: optional
Architecture: amd64
Maintainer: Your Name <you@example.com>
Description: A powerful CLI tool for log analysis
 This tool helps developers quickly parse and analyze
 server logs with high performance.

打包命令很简单：

dpkg-deb --build mytool-1.0.0

我在项目中遇到过一个问题：control文件里忘了写 Depends 字段。结果用户安装时没报错，运行时却提示缺少库。后来我养成了习惯，每次打包前先用 ldd 检查一遍依赖：

ldd mytool | grep "not found"

28.4 rpm包制作——Red Hat/CentOS系

rpm包的制作稍微复杂一点，但套路是固定的。你需要一个 .spec 文件来描述打包规则。

一个典型的spec文件：

Name: mytool
Version: 1.0.0
Release: 1%{?dist}
Summary: A powerful CLI tool for log analysis

License: MIT
URL: https://example.com/mytool
Source0: %{name}-%{version}.tar.gz

BuildRequires: gcc, make
Requires: glibc >= 2.17

%description
This tool helps developers quickly parse and analyze
server logs with high performance.

%prep
%setup -q

%build
make %{?_smp_mflags}

%install
mkdir -p %{buildroot}%{_bindir}
install -m 755 mytool %{buildroot}%{_bindir}/

%files
%{_bindir}/mytool

%changelog
* Mon Jan 15 2024 Your Name <you@example.com> - 1.0.0-1
- Initial release

构建命令：

rpmbuild -ba mytool.spec

我的经验：rpm打包最容易翻车的地方是 %files 段。如果你漏掉了某个文件，安装时会报「文件未打包」的错误。我建议先用 rpm -qpl 查看生成的rpm包里有哪些文件，确认无误再发布。

28.5 安装脚本编写

有些场景下，deb/rpm包不够灵活。比如你的工具需要创建配置文件、设置环境变量、或者注册系统服务。这时候就需要安装脚本了。

我常用的安装脚本结构：

#!/bin/bash
# install.sh - mytool 安装脚本

set -e  # 出错即停

INSTALL_DIR="/usr/local/bin"
CONFIG_DIR="/etc/mytool"
DATA_DIR="/var/lib/mytool"

echo "正在安装 mytool v1.0.0..."

# 1. 复制二进制
install -d "$INSTALL_DIR"
install -m 755 mytool "$INSTALL_DIR/"

# 2. 创建配置目录
install -d "$CONFIG_DIR"
if [ ! -f "$CONFIG_DIR/config.yaml" ]; then
    install -m 644 config.yaml "$CONFIG_DIR/"
    echo "已创建默认配置文件"
fi

# 3. 创建数据目录
install -d "$DATA_DIR"

# 4. 设置环境变量
if ! grep -q "MYTOOL_HOME" /etc/profile.d/mytool.sh 2>/dev/null; then
    echo "export MYTOOL_HOME=$DATA_DIR" > /etc/profile.d/mytool.sh
    echo "已设置环境变量"
fi

# 5. 验证安装
if command -v mytool >/dev/null; then
    echo "安装成功！运行 mytool --help 查看帮助"
else
    echo "安装失败，请检查权限"
    exit 1
fi

卸载脚本同样重要：

#!/bin/bash
# uninstall.sh - mytool 卸载脚本

echo "正在卸载 mytool..."

rm -f /usr/local/bin/mytool
rm -rf /etc/mytool
rm -rf /var/lib/mytool
rm -f /etc/profile.d/mytool.sh

echo "卸载完成"

我曾经踩过的坑：卸载脚本里直接 rm -rf /etc/mytool，结果用户自己把配置文件改过，一卸载全没了。后来我改成先备份再删除：cp -r /etc/mytool /tmp/mytool-backup-$(date +%Y%m%d)。用户至少有个后悔药。

28.6 版本管理——别让你的用户困惑

版本号不是随便写的。我见过有人用 v1、v2、v3-final、v3-final-真的最终版……这简直是灾难。

我推荐使用语义化版本（SemVer）：

格式	示例	说明
主版本.次版本.修订号	1.2.3	主版本：不兼容的API变更次版本：向下兼容的新功能修订号：向下兼容的问题修复
预发布版本	1.0.0-alpha.1	用于测试，不保证稳定
构建元数据	1.0.0+build.20240115	附加信息，不影响版本优先级

在代码里，我习惯把版本号定义在头文件中：

// version.h
#define MYTOOL_VERSION_MAJOR 1
#define MYTOOL_VERSION_MINOR 2
#define MYTOOL_VERSION_PATCH 3
#define MYTOOL_VERSION_STRING "1.2.3"

然后在 --version 参数里输出：

printf("mytool version %s\n", MYTOOL_VERSION_STRING);

28.7 知识体系总览

下面这张图概括了本章的核心逻辑：

28.8 一些实用建议

最后，分享几个我这些年攒下来的经验：

自动化打包：别手动敲命令。写个Makefile或者shell脚本，一键生成所有格式的包。我自己的项目里，make release 会同时生成deb、rpm和静态二进制。
测试安装包：在干净的Docker容器里测试你的包。用 docker run --rm -it ubuntu:latest 装一遍，看能不能跑。
签名你的包：deb包用 dpkg-sig，rpm包用 rpm --addsign。用户能验证包的真伪，安全又专业。
保留构建记录：每次发布，把源码、spec文件、构建日志归档。万一出问题，能回溯到具体版本。

一个小技巧：在二进制里嵌入版本号和构建时间。这样用户报bug时，你一眼就能看出他用的是哪个版本：

const char* build_info = "mytool v1.2.3 (built on 2024-01-15 by jenkins)";

打包发布这件事，说白了就是「让用户省心」。你多花一小时做包，可能帮几百个用户每人省下半小时。这笔账，怎么算都划算。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录