termux-packages 如何用 run-docker.sh 进入官方 Docker 构建容器并执行第一个构建【免费下载链接】termux-packagesA package build system for Termux.项目地址: https://gitcode.com/GitHub_Trending/te/termux-packagestermux-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等安全选项创建容器macOSDarwin分支下仓库根目录取$PWD当前工作目录且不附加上述安全选项所以在 macOS 上必须在仓库根目录内运行脚本。AppArmorLinux 主机上如果检测到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。执行过程中的关键行为若同名容器不存在脚本先创建容器docker run --detach --init --name termux-package-builder并把仓库根目录挂载到容器内的/home/builder/termux-packages。检测到 SELinux 处于 Enforcing如 Fedora时挂载参数会自动追加:z后缀以避免权限问题脚本注释里给出的检查命令是ls -Z .重置命令是restorecon -Fr .。容器内工作用户是builderuid 1001见 scripts/Dockerfile。如果宿主机用户 uid 既不是 1001 也不是 0脚本会执行Changed builder uid/gid...流程在容器内用chown/usermod/groupmod把builder的 uid/gid 改成与宿主机一致原文提示this may take a while这一步会修改容器内文件属主与用户配置。脚本会检查并把/proc/sys/kernel/pid_max设为 65535用于需要 proot 运行 32 位原生命令的包。如果无法在容器命名空间内生效会回退到修改宿主机内核参数脚本明确提示may affect other processes on the host system。最后通过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 环境可通过CItrue让脚本在docker exec时附加--env CItrue。第二步在容器内执行第一个构建进入 shell 后你已位于/home/builder/termux-packagesDockerfile 中声明的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是不构建、直接下载解包依赖的替代路径两者不要在同一条命令里混用。验证构建结果两处可以核对容器本身脚本内部用docker container inspect判断容器是否存在你可以用同样的方式确认容器处于预期状态docker container inspect termux-package-builder构建产物按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回退到宿主机写入时可能影响宿主机上的其他进程脚本会打印对应提示看到提示时按脚本输出判断是否成功即可。容器内禁止 sudobuild-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
termux-packages 如何用 run-docker.sh 进入官方 Docker 构建容器并执行第一个构建？
termux-packages 如何用 run-docker.sh 进入官方 Docker 构建容器并执行第一个构建【免费下载链接】termux-packagesA package build system for Termux.项目地址: https://gitcode.com/GitHub_Trending/te/termux-packagestermux-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等安全选项创建容器macOSDarwin分支下仓库根目录取$PWD当前工作目录且不附加上述安全选项所以在 macOS 上必须在仓库根目录内运行脚本。AppArmorLinux 主机上如果检测到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。执行过程中的关键行为若同名容器不存在脚本先创建容器docker run --detach --init --name termux-package-builder并把仓库根目录挂载到容器内的/home/builder/termux-packages。检测到 SELinux 处于 Enforcing如 Fedora时挂载参数会自动追加:z后缀以避免权限问题脚本注释里给出的检查命令是ls -Z .重置命令是restorecon -Fr .。容器内工作用户是builderuid 1001见 scripts/Dockerfile。如果宿主机用户 uid 既不是 1001 也不是 0脚本会执行Changed builder uid/gid...流程在容器内用chown/usermod/groupmod把builder的 uid/gid 改成与宿主机一致原文提示this may take a while这一步会修改容器内文件属主与用户配置。脚本会检查并把/proc/sys/kernel/pid_max设为 65535用于需要 proot 运行 32 位原生命令的包。如果无法在容器命名空间内生效会回退到修改宿主机内核参数脚本明确提示may affect other processes on the host system。最后通过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 环境可通过CItrue让脚本在docker exec时附加--env CItrue。第二步在容器内执行第一个构建进入 shell 后你已位于/home/builder/termux-packagesDockerfile 中声明的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是不构建、直接下载解包依赖的替代路径两者不要在同一条命令里混用。验证构建结果两处可以核对容器本身脚本内部用docker container inspect判断容器是否存在你可以用同样的方式确认容器处于预期状态docker container inspect termux-package-builder构建产物按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回退到宿主机写入时可能影响宿主机上的其他进程脚本会打印对应提示看到提示时按脚本输出判断是否成功即可。容器内禁止 sudobuild-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
