Trippy Ubuntu/Debian 打包发布全流程：从 PPA 构建到 dput 上传-育师

Trippy Ubuntu/Debian 打包发布全流程：从 PPA 构建到 dput 上传

【免费下载链接】trippyA network diagnostic tool项目地址: https://gitcode.com/GitHub_Trending/tr/trippy

本篇技术指南以仓库中 ubuntu-ppa/README.md 为核心，系统讲解 Trippy（一款结合 traceroute 与 ping 的网络诊断工具）如何构建并发布 Debian/Ubuntu 软件包到 Launchpad PPA（Personal Package Archive）。你将掌握：发布前的版本与工具链同步检查清单、基于 Docker 的离线化打包流水线、cargo vendor 依赖固化的原理，以及使用 dput 上传.changes文件到 PPA 的完整命令序列，可直接照搬用于 Trippy 的日常发版。

一、发布前置条件：版本号与工具链的四项同步清单

在动手构建之前，ubuntu-ppa/README.md明确列出必须先完成的准备工作，核心原则是所有涉及 Rust 工具链版本与 Trippy 版本号的地方必须保持一致，否则 debuild 构建或 dput 上传会失败。逐项核对如下：

文件	需要更新的内容	说明
ubuntu-ppa/Dockerfile	`cargo`与`cargo-1.xx`两个包	README 特别提示：apt 安装列表中`cargo`与`cargo-1.xx`两者都需要，前者提供`cargo`命令入口，后者锁定具体工具链版本
ubuntu-ppa/control	`cargo-1.xx`、`rustc-1.xx`	声明构建依赖，当前仓库使用`cargo-1.88`、`rustc-1.88`、`libstd-rust-dev`
ubuntu-ppa/rules	`cargo-1.xx`	构建规则中调用`cargo-1.88 build --release --frozen`
ubuntu-ppa/release.sh	`cargo-1.88`、`VERSION`、`UPSTREAM`、`REVISION`	脚本内同时引用工具链版本与 Trippy 版本号

其中release.sh顶部的一组变量是版本管理的核心，逐项说明其含义：

# The Trippy version to release VERSION="0.14.0-dev" # The upstream version to use in the PPA # 若上游 tarball 被重新打包（repack），需追加 +repack{N} 后缀，例如 0.1.0+repack1 UPSTREAM="0.14.0-dev" # The revision number for the PPA # 每次向 PPA 上传新包时递增，总是比 repack 次数大 1 REVISION=1

依据release.sh中的注释与脚本逻辑：

VERSION决定从 GitHub 下载哪个 tag 的源码 tarball；
UPSTREAM是写入 PPA 的上游版本号，必须去掉任何+repack{N}后缀（README 原文要求：removing any+repack{N}suffix）；
REVISION是 PPA 内部分发的修订号，每次发版必须重置回1；
SERIES=("resolute")声明要构建的 Ubuntu 发行版系列，当前仓库以resolute为目标。

二、构建环境：基于 Docker 的 Debian 打包镜像

整个打包流程被封装进一个 Docker 镜像，实现构建环境的完全可复现。先看 ubuntu-ppa/Dockerfile 的完整内容：

FROM ubuntu:resolute ENV DEBIAN_FRONTEND=noninteractive RUN apt-get update && apt-get install -y \ gpg debmake debhelper devscripts equivs \ distro-info-data distro-info software-properties-common cargo cargo-1.88 wget COPY release.sh release.sh WORKDIR /data CMD ["./ubuntu-ppa/release.sh"]

各依赖包在流水线中的作用：

gpg：导入用于签名.changes/.dsc文件的 Launchpad PGP 密钥；
debmake/debhelper/devscripts：Debian 打包的标准工具集，debuild、dch均来自这里；
equivs：可生成满足构建依赖的伪包（备用于缺失的系统依赖）；
distro-info-data/distro-info：release.sh通过distro-info --series "${series}" -r查询指定 Ubuntu 系列对应的版本号，用于构造形如~ubuntu24.04的版本后缀；
software-properties-common：提供add-apt-repository，便于在容器内添加额外软件源（例如 cargo 官方源）；
cargo+cargo-1.88：如 README 所强调，两个包缺一不可。

三、两步构建：构建镜像 → 运行容器

ubuntu-ppa/README.md给出的构建步骤分两步：

第一步：在ubuntu-ppa目录下构建打包镜像

docker build . -t fujiapple/trippy-ppa-build:latest

第二步：从仓库根目录运行该镜像

docker run -it -v (pwd):/data fujiapple/trippy-ppa-build

关键点解析：

在构建镜像前，需要先把 PGP 私钥复制到仓库根目录（README原文为 reporootdirectory）：
```
cp /path/to/pgp.key .
```
release.sh中对应的查找逻辑是launchpad_secret_key.pgp，密钥缺失时脚本会立即报错退出；容器通过-v (pwd):/data将仓库根目录挂载为工作目录/data，CMD启动后执行./ubuntu-ppa/release.sh，脚本路径、密钥文件、vendor tarball 都会写到挂载卷中；
注意：README特别提示docker run命令应在repo root（仓库根目录）执行，而docker build则在ubuntu-ppa 目录执行，两者工作目录不同，不要混淆。

四、release.sh 内部流程：签名校验、依赖固化与多系列构建

docker run触发容器内的 ubuntu-ppa/release.sh，其执行流水线可以拆解为五个阶段，这些细节是ubuntu-ppa/README.md未展开、但从脚本源码中可以完整还原的：

4.1 GPG 密钥导入与过期校验

if [[ ! -f launchpad_secret_key.pgp ]]; then echo "Error: GPG key file 'launchpad_secret_key.pgp' not found." >&2 exit 1 fi gpg --batch --import launchpad_secret_key.pgp GPG_KEY_ID=$(gpg --with-colons --import-options show-only --import launchpad_secret_key.pgp | awk -F: '/^sec/ {print $5}') if gpg --list-keys --with-colons "${GPG_KEY_ID}" | grep '^pub' | grep '[e]'; then echo "GPG key has expired. Please update your GPG key." >&2 exit 1 fi

脚本先确认密钥文件存在，再批量导入，并通过gpg --with-colons解析出主密钥 ID；随后检查密钥是否过期，过期则直接终止发版。这一步对应 README 中"Copy the pgp key to the repo root directory"的后续动作，也是 Launchpad 签名认证的前提。

4.2 下载上游源码 tarball

wget -O "${TARBALL}" "https://github.com/fujiapple852/trippy/archive/refs/tags/${VERSION}.tar.gz"

即trippy_${UPSTREAM}.orig.tar.gz。注意这里依赖 GitHub tag 存在，且 tarball 名称中的版本号取UPSTREAM，与下载地址中的VERSION相互独立——这正是 README 要求"移除+repack{N}后缀"的原因：UPSTREAM参与文件名与 PPA 版本号，必须保持纯净的语义化版本。

4.3 cargo vendor 依赖固化（构建的核心环节）

tar -xf "${TARBALL}" pushd "trippy-${VERSION}" rm -f ../ubuntu-ppa/vendor.tar.xz rm -rf vendor cargo-1.88 vendor --locked tar -cJf ../ubuntu-ppa/vendor.tar.xz vendor popd rm -rf "trippy-${VERSION}"

脚本注释特别强调：cargo vendor --locked必须针对tarball 内的源码运行，而不是当前目录（仓库根目录）的源码，以确保与 tag 对应的Cargo.lock完全一致。固化的依赖被压缩为ubuntu-ppa/vendor.tar.xz。

这一设计的动机在 ubuntu-ppa/README.debian 中有明确阐述：Debian 与 Canonical 的自动构建系统不允许联网解析依赖，因此必须用cargo vendor把所有 crates.io 依赖离线打包；构建时通过rules中的--frozen选项强制 Cargo 禁止访问网络。对应地：

ubuntu-ppa/rules 在override_dh_auto_build中先创建.cargo目录、把debian/cargo.config复制为 Cargo 配置，再解包vendor.tar.xz，最后执行cargo-1.88 build --release --frozen；

ubuntu-ppa/cargo.config 内容如下，将 crates.io 源重定向到本地 vendor 目录：

[source.crates-io] replace-with = "vendored-sources" [source.vendored-sources] directory = "vendor"

ubuntu-ppa/source/include-binaries 声明debian/vendor.tar.xz是随源码包一起分发的二进制文件；
对应的清理逻辑在override_dh_auto_clean：cargo-1.88 clean并删除.cargo与vendor目录。

4.4 按发行版系列生成 changelog 并构建源码包

for series in "${SERIES[@]}"; do UBUNTU_VERSION=$(distro-info --series "${series}" -r | cut -d' ' -f1) BUILD_DIR="build-${series}" mkdir -p "${BUILD_DIR}" cp -r ubuntu-ppa "${BUILD_DIR}/debian" cd "${BUILD_DIR}" rm -f debian/changelog dch --create --distribution "${series}" --PACKAGE "${PACKAGE}" \ --newversion "${UPSTREAM}-ppa${REVISION}~ubuntu${UBUNTU_VERSION}" "$CHANGES" debuild --prepend-path ~/.cargo/bin -S -sa cd .. done

对每个目标系列：用distro-info查询其 Ubuntu 版本号，把ubuntu-ppa整目录复制为build-<series>/debian，再用dch以0.14.0-dev-ppa1~ubuntu25.10这种格式生成 changelog（仓库中的 ubuntu-ppa/changelog 展示了trippy (0.14.0-dev-ppa2~ubuntu24.04) noble的历史记录），最后以-S（源码包）与-sa（包含 orig tarball）模式调用debuild。

4.5 上传到 PPA

for changes_file in ./*.changes; do dput ppa:fujiapple/trippy "${changes_file}" done

脚本将每个系列生成的.changes文件通过dput上传到 Launchpad 上名为ppa:fujiapple/trippy的 PPA。这正是ubuntu-ppa/README.md结尾提示的模拟开关生效之处：

Note that the upload is simulated, remove the-ssflag from dput to upload the package to the PPA.

即：脚本中dput ppa:fujiapple/trippy "${changes_file}"等价于带-ss（simulate）参数运行，仅做模拟；去掉该标志才会真正执行上传。如果你还没有准备好正式上传，保持模拟状态即可安全地验证整个流水线。

五、打包产物与安装方式

构建完成后，ubuntu-ppa/trippy.install 定义了安装规则——将target/release/trip安装到/usr/bin；ubuntu-ppa/trippy.docs 则会把README.md装入文档目录。

用户在 Ubuntu 上通过 PPA 安装 Trippy 的方式（见仓库 README.md 的 PPA 章节）：

add-apt-repository ppa:fujiapple/trippy apt update apt install trippy

PPA 仅面向特定 Ubuntu LTS 发行版（例如 24.04 Noble、22.04 Jammy），安装前请确认你的系统版本与所发布 PPA 的目标系列匹配。

六、扩展参考：手动构建与多发行版适配

如果你不需要 Docker 流水线，ubuntu-ppa/README.debian 给出了手动路径：先在源码目录运行./debian/rules vendor生成debian/vendor.tar.xz，只要父目录存在trippy_<version>.orig.tar.gz，即可直接执行debuild --prepend-path ~/.cargo/bin -sa构建；上传时依次运行debuild --prepend-path ~/.cargo/bin -S -sa与dput <your ppa> ../<source_package_name>.changes。

同一份debian目录可以通过修改 changelog 中的版本与发行版字段来适配其他系列，例如：

trippy (0.14.0-dev-1ubuntu0.1~jammy1) jammy; urgency=medium trippy (0.14.0-dev-1ubuntu0.1~mantis1) mantis; urgency=medium trippy (0.14.0-dev-1ubuntu0.1~noble1) noble; urgency=medium

官方推荐使用debchange而非手工编辑：debchange --distribution noble --newversion 0.14.0-dev-1ubuntu0.1~noble1。

七、发布流程核对清单

将本文要点浓缩为一次发版的可执行清单：

更新ubuntu-ppa/Dockerfile中的cargo与cargo-1.xx（两者都要）；
同步更新control中的cargo-1.xx、rustc-1.xx；
同步更新rules与release.sh中的cargo-1.xx；
更新release.sh中的VERSION与UPSTREAM（去掉+repack{N}后缀），并将REVISION重置为1；
将 PGP 密钥复制到仓库根目录；
在ubuntu-ppa目录执行docker build . -t fujiapple/trippy-ppa-build:latest；
在仓库根目录执行docker run -it -v (pwd):/data fujiapple/trippy-ppa-build；
检查.changes输出无误后，从dput命令中去掉-ss标志正式上传。

如需深入理解打包规则的每一处细节，可直接阅读 ubuntu-ppa/Dockerfile、ubuntu-ppa/release.sh、ubuntu-ppa/rules、ubuntu-ppa/control 与 ubuntu-ppa/README.debian 五个文件，它们共同构成了 Trippy 在 Debian/Ubuntu 生态中的完整发布链路。

【免费下载链接】trippyA network diagnostic tool项目地址: https://gitcode.com/GitHub_Trending/tr/trippy

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考