企业官网建设流程全解析

termux-packages 如何用 run-docker.sh 进入官方 Docker 构建容器并执行第一个构建？

【免费下载链接】termux-packagesA package build system for Termux.项目地址: https://gitcode.com/GitHub_Trending/te/termux-packages

termux-packages 是一个面向 Termux 的打包构建系统，仓库里每个包都有一份build.sh配方，构建流程本身在 Android 之外的环境完成。如果你想在本地编译出第一个 .deb 包，官方提供的入口是 scripts/run-docker.sh：它会基于官方构建镜像ghcr.io/termux/package-builder创建并进入一个名为termux-package-builder的容器，把仓库根目录挂载到容器内，让你可以直接运行 build-package.sh 完成构建。本文适用环境是已安装 Docker 的主机（脚本对 Linux 与 macOS 分别处理），目标是完整走通"进入容器 → 构建一个包 → 验证产物"这条路径。

准备条件

在运行脚本之前，确认以下事项（均来自脚本与 Dockerfile 的说明）：

• 主机系统：Linux 下脚本通过脚本自身路径解析仓库根目录，并以--security-opt seccomp=... --security-opt apparmor=... --cap-add CAP_SYS_ADMIN --device /dev/fuse等安全选项创建容器；macOS（Darwin）分支下仓库根目录取$PWD（当前工作目录），且不附加上述安全选项，所以在 macOS 上必须在仓库根目录内运行脚本。
• AppArmor：Linux 主机上如果检测到apparmor_parser且 AppArmor 已启用，脚本会自动用sudo apparmor_parser -rK依次加载 scripts/profile-relaxed.apparmor 和 scripts/profile-restricted.apparmor。找不到apparmor_parser时脚本会打印警告并继续运行，原文提示"这不推荐，可能导致安全问题与意外行为，避免在容器中执行不可信代码"。
• docker 权限：如果你的docker命令需要 root，设置环境变量TERMUX_DOCKER_USE_SUDO为任意非空值，脚本会给所有docker命令加上sudo前缀。
• 可覆盖的环境变量：TERMUX_BUILDER_IMAGE_NAME（镜像名，默认ghcr.io/termux/package-builder）和CONTAINER_NAME（容器名，默认termux-package-builder）。

第一步：用 run-docker.sh 进入构建容器

在仓库根目录执行：

./scripts/run-docker.sh

不带任何命令参数时，脚本会以bash启动一个交互式 shell。执行过程中的关键行为：

1. 若同名容器不存在，脚本先创建容器（docker run --detach --init --name termux-package-builder），并把仓库根目录挂载到容器内的/home/builder/termux-packages。检测到 SELinux 处于 Enforcing（如 Fedora）时，挂载参数会自动追加:z后缀以避免权限问题；脚本注释里给出的检查命令是ls -Z .，重置命令是restorecon -Fr .。
2. 容器内工作用户是builder（uid 1001，见 scripts/Dockerfile）。如果宿主机用户 uid 既不是 1001 也不是 0，脚本会执行"Changed builder uid/gid..."流程，在容器内用chown/usermod/groupmod把builder的 uid/gid 改成与宿主机一致，原文提示"this may take a while"（这一步会修改容器内文件属主与用户配置）。
3. 脚本会检查并把/proc/sys/kernel/pid_max设为 65535（用于需要 proot 运行 32 位原生命令的包）。如果无法在容器命名空间内生效，会回退到修改宿主机内核参数，脚本明确提示"may affect other processes on the host system"。
4. 最后通过docker exec --interactive进入容器。你在容器里的起始目录就是/home/builder/termux-packages，即宿主机仓库的挂载点。

可选参数（来自脚本的--help输出）：

• -h, --help：显示帮助。
• -d, --dry-run：构建前先运行build-package-dry-run-simulation.sh，仅当首个参数路径包含build-package.sh时生效；模拟结果为"无需构建任何包"（退出码 85）时直接退出。
• -m, --mount-termux-dirs：额外把宿主机的/data与~/.termux-build挂载进容器，用于配合宿主机 IDE/编辑器的本地开发场景。

注意：TERMUX_DOCKER_RUN_EXTRA_ARGS（以及-m引入的挂载参数）只在创建容器时生效；如果容器已存在，要应用新参数必须先把现有容器删掉。CI 环境可通过CI=true让脚本在docker exec时附加--env CI=true。

第二步：在容器内执行第一个构建

进入 shell 后你已位于/home/builder/termux-packages（Dockerfile 中声明的WORKDIR），也就是仓库根目录。构建入口是 build-package.sh，其用法为：

Usage: ./build-package.sh [options] PACKAGE_1 PACKAGE_2 ...

它的作用（引用脚本帮助原文）是"Build a package by creating a .deb file in the output/ folder."。第一次构建可以选一个配方极简的包——packages/hello/build.sh 只声明了libiconv一个依赖和少量变量，是合适的起步对象：

./build-package.sh hello

与首次构建相关的几个常用选项（摘自build-package.sh的帮助输出）：

• -a：指定目标架构，aarch64（默认）、arm、i686、x86_64或all；
• -j <N>：构建线程数，默认取nproc；
• -i：下载并解包已发布的依赖，而不是本地构建依赖；
• -f/-F：强制重建（-F连同依赖一起强制）；
• -o：指定构建产物输出目录，默认output/；
• -s：跳过依赖检查。

依赖默认按配方声明的顺序参与构建；-i是"不构建、直接下载解包依赖"的替代路径，两者不要在同一条命令里混用。

验证构建结果

两处可以核对：

1. 容器本身：脚本内部用docker container inspect判断容器是否存在，你可以用同样的方式确认容器处于预期状态：

   docker container inspect termux-package-builder

2. 构建产物：按build-package.sh的用法说明，构建成功后output/目录下会生成 .deb 文件。在容器内执行：

   ls output/

   能看到hello及其依赖（如libiconv）对应的 .deb 文件，说明这条构建路径已走通。

更新构建镜像

镜像更新有独立脚本 scripts/update-docker.sh：它先docker pull ghcr.io/termux/package-builder，然后比较容器当前使用的镜像 id 与最新镜像 id。注意副作用：一旦镜像有更新，脚本会执行docker stop termux-package-builder和docker rm -f termux-package-builder，即停止并删除现有容器，容器内的运行状态（不含挂载的仓库文件）随之丢失。确认需要刷新镜像后再运行：

./scripts/update-docker.sh

镜像本身如何构建见 scripts/Dockerfile 中的注释：基于ubuntu:26.04，创建免密 sudo 的builder用户（uid 1001），运行setup-ubuntu.sh、setup-android-sdk.sh、setup-cgct.sh完成工具链安装，注释中给出的构建命令是docker build -t ghcr.io/termux/package-builder .。普通使用场景不需要自行重建镜像，直接用run-docker.sh拉取官方镜像即可。

限制与已知注意事项

• AppArmor 缺失不是错误：脚本会继续运行，但官方注释明确建议不要在此情况下执行不可信代码。
• TERMUX_DOCKER_RUN_EXTRA_ARGS的生效时机：只在创建容器时生效，改参数必须先删除已有容器（用docker rm前先确认容器可安全停止，此操作会移除容器实例）。
• macOS 差异：Darwin 分支以$PWD作为仓库根目录且不附加 seccomp/AppArmor 安全选项，在根目录外运行会导致挂载到错误位置。
• 宿主机内核参数：pid_max回退到宿主机写入时可能影响宿主机上的其他进程，脚本会打印对应提示，看到提示时按脚本输出判断是否成功即可。
• 容器内禁止 sudo：build-package.sh在构建脚本中显式禁用sudo，环境配置问题应通过官方 setup 脚本解决，而不是在容器里提权操作。

完成上述流程后，你得到的验证结果就是：docker container inspect确认容器存在且基于最新镜像，output/中出现构建出的 .deb 文件。后续如果要持续维护某个包的配方（版本升级、补丁修复），CONTRIBUTING.md 中的 "Updating packages" 一节给出了TERMUX_PKG_VERSION、TERMUX_PKG_SHA256与TERMUX_PKG_REVISION的具体修改规则，可以对照执行。

【免费下载链接】termux-packagesA package build system for Termux.项目地址: https://gitcode.com/GitHub_Trending/te/termux-packages