Apache Arrow Linux 软件包构建全指南用 Rake 与 Docker 打包 C/GLib 的 .deb 与 .rpm 安装包【免费下载链接】arrowApache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing项目地址: https://gitcode.com/gh_mirrors/arrow13/arrowApache Arrow 在 dev/tasks/linux-packages/README.md 中描述了为 Arrow C 与 Arrow GLib 构建 Linux 安装包的官方流程先rake version:update更新版本信息再通过rake apt或rake yum在 Docker 容器内分别产出 Debian.deb与 RPM.rpm系列软件包。本文以这份文档为核心结合仓库中完整的 Rake 任务、打包脚本、Dockerfile 与 CI 模板深入讲解从版本探测、模板替换到最终仓库目录产出的完整链路读完即可独立复现或改造这一套打包体系。为什么需要一套独立的 Linux 打包链路Apache Arrow 是一个跨语言的数据交换与内存处理工具箱其 C 核心库cpp/与基于 GLib 的 C 语言绑定层c_glib/是众多语言绑定的底层依赖。为了让 Debian/Ubuntu 用户能够apt install libarrow-dev、让 CentOS/AlmaLinux 用户能够yum install arrow-devel官方在dev/tasks/linux-packages/目录中维护了一套统一的打包流水线同一份源码被分别加工成符合 Debian 规范debian/目录 debuild和 RPM 规范.spec文件 rpmbuild的产物。这套体系的核心设计是用RakeRuby 的任务编排工具统一驱动所有步骤支持rake version:update、rake apt、rake yum、rake docker:pull/push等任务用Docker为每个目标发行版/架构提供干净的构建环境保证可复现性支持dev/rc/正式版三种版本形态的版本号映射自动生成 changelog 与 spec 变更记录。环境要求原文档明确列出的前置条件见 README.mdRuby用于执行 Rake 任务Docker用于在对应发行版容器内完成实际编译打包构建 tar.gz 的工具打包前需要先生成 Apache Arrow C 与 GLib 的源码压缩包git用于git archive生成源码包curl/网络用于下载正式发布包。此外从 helper.rb 的源码可见版本探测还依赖java/pom.xml读取当前 SNAPSHOT 版本号与 Git 历史用于获取最近一次提交时间作为 release time因此运行环境还需要 Git 与一个已检出的 Arrow 仓库。快速上手构建 .deb 软件包按原文档操作即可% rake version:update % rake aptrake version:update会遍历packages数组中的三个子包并逐个执行其version:update任务见 Rakefile主要做两件事实现在 package-task.rb 中更新各debian*/changelog在文件头部插入形如apache-arrow (17.0.0-1) unstable; urgencylow的新条目update_debian_changelog更新yum/*.spec.in中的%changelog段落并确保Release:字段为1update_spec。随后rake apt触发apt:build依次对三个子包执行rake apt:build。最终 .deb 产物会落在各子包的apt/repositories/目录下形成可供apt使用的 pool 结构。快速上手构建 .rpm 软件包% rake version:update % rake yum与 APT 流程对称rake yum触发yum:build在 Docker 容器内调用rpmbuild -ba构建二进制包与源码包SRPM产物落在各子包的yum/repositories/目录下目录结构为发行版/版本/架构/Packages/详见后文 yum/build.sh 的分析。注意两次构建前都需要先执行rake version:update因为它同时维护 deb 的 changelog 与 rpm 的 spec changelog跳过会导致版本记录不一致。顶层 Rakefile三个子包如何被编排dev/tasks/linux-packages/Rakefile是整条流水线的总入口它声明了要打包的包集合packages [ apache-arrow, # 真正的 Arrow C / GLib 库与工具 apache-arrow-apt-source, # 面向 APT 的仓库安装辅助包含 GPG 密钥 apache-arrow-release, # 面向 YUM 的仓库安装辅助包含 .repo 与 GPG 密钥 ]每个子目录都是一个独立的 Rake 项目有自己的Rakefile。顶层文件通过cd(package) { ruby(-S, rake, apt:build) }逐包调用把apt:build、yum:build、version:update、docker:pull、docker:push五个命名空间的任务统一收敛。文件末尾还定义了ApacheArrowLocalBinaryTask它继承自 dev/release/binary-task.rb 中的LocalBinaryTask把本地构建产物与发布任务如apt:test、yum:test的验证逻辑接入了更大的 Apache Arrow 发布体系。版本探测与三态版本号映射打包的第一件事是确定版本号。Helper::ApacheArrowhelper.rb提供了两个关键探测函数detect_release_time优先取环境变量ARROW_RELEASE_TIME否则取 Arrow 仓库最近一次 git commit 的提交时间git log -n 1 --format%aI再退化为当前时间detect_version优先取环境变量ARROW_VERSION否则解析 java/pom.xml 中的version字段如当前仓库的17.0.0-SNAPSHOT并把-SNAPSHOT替换为-devYYYYMMDD日期来自 release time。拿到版本号后PackageTask#initialize 按三种形态映射 Debian 与 RPM 的版本规范版本形态deb 上游版本deb_upstream_versionRPM 版本 / Release正式版如17.0.017.0.017.0.0/1rc 版如17.0.0-rc1且 rc_build_type 非 release17.0.0~rc1~使 rc 排序低于正式版17.0.0/0.rc1dev 版如17.0.0-dev2024010117.0.0~dev2024010117.0.0/0.dev20240101同时deb_release ENV[DEB_RELEASE] || 1允许通过环境变量覆盖 deb 包的 Debian 修订号。这套映射是保证 apt 与 yum 的依赖比较器~、0.rc等约定行为正确的关键。Docker 化的构建内核无论是 APT 还是 YUM实际编译都在容器内完成。PackageTask#docker_runpackage-task.rb是核心docker build --cache-from image --tag image构建构建镜像利用上一次产物做缓存加速docker run --rm --volume $PWD:/host:rw把当前打包目录挂载进容器容器内脚本通过/host/...访问源码包、spec 与环境变量文件若设置了BUILD_DIR环境变量会额外把${BUILD_DIR}/target挂载到容器的/build作为独立的编译工作区便于 CI 持久化 ccache支持DEBUGyes时向容器透传DEBUG并显示完整构建输出透传DEB_BUILD_OPTIONS与RPM_BUILD_NCPUS两个环境变量如DEB_BUILD_OPTIONSparallel8、RPM_BUILD_NCPUS8容器内默认执行/host/build.sh带console: true的rake apt:build:console/rake yum:build:console则以交互模式进入容器方便调试。构建镜像的两种定义方式目录中存在Dockerfile时直接使用如 ubuntu-jammy/Dockerfile基于ubuntu:jammy并安装build-essential、cmake、debhelper、meson、ninja-build及 Arrow 所需的全部依赖库否则读取from文件如 ubuntu-focal-arm64/from 内容为arm64v8/ubuntu:focal并把镜像名通过--build-arg FROM...传入 Dockerfile 的ARG FROM。镜像命名Helper::ApacheArrow#docker_imagehelper.rb定义为${REPO}:${architecture}-${os}-package-${package}其中REPO来自环境变量或仓库根目录下的.env文件。arm64 交叉场景下 package-task.rb 会自动从docker build切换到docker buildx build --platformlinux/arm64。目标列表默认 APT 目标是debian-bookworm、debian-trixie、ubuntu-focal、ubuntu-jammy、ubuntu-noblearm64 变体默认注释掉见apt_targets_default默认 YUM 目标是almalinux-9/8、amazon-linux-2023、centos-9-stream/8-stream、centos-7。可用环境变量APT_TARGETS、YUM_TARGETS逗号分隔覆盖默认列表只有目录真实存在的目标才会被构建。APT.deb构建链路源码包准备apache-arrow/Rakefileapache-arrow/Rakefile的define_archive_task按版本形态决定源码包来源17.0.0-rc1形态从 Apache 的 dist 开发目录下载对应 rc 归档17.0.0形态从 Apache 镜像站closer.lua解析并下载正式发布归档其他形态dev 快照直接在仓库根目录执行git archive HEAD --prefix apache-arrow-version/生成 tar.gz。debian/ 打包元数据apache-arrow/debian/目录是标准的 Debian 打包元数据集合control.in定义全部二进制包。PackageTask#apt_prepare_debian_dir会在构建前把debian目录复制到临时区并对control.in做模板替换生成control。ApacheArrowPackageTask#apt_prepare_debian_controlapache-arrow/Rakefile替换三个占位符CUDA_ARCHITECTURECUDA 相关包libarrow-cuda1700等的Architecture字段默认i386 amd64USE_SYSTEM_GRPC/USE_SYSTEM_PROTOBUFUbuntu Focal 由于系统库版本过旧以#注释掉系统 gRPC/protobuf 依赖改为使用 Arrow 自带依赖。rulesdh构建脚本。C 部分用cmakeninja显式开启-DARROW_CSVON、-DARROW_DATASETON、-DARROW_FLIGHTON、-DARROW_GANDIVAON、-DARROW_ORCON、-DARROW_PARQUETON等组件并设置-DARROW_PACKAGE_KINDdeb随后用mesonninja构建c_glib并开启 GObject Introspection-Dvapitrue -Ddoctrue。构建完成后会清理中间产物以节省磁盘。*.install文件决定每个二进制包装入哪些文件例如libarrow1700.install装共享库、libarrow-dev.install装头文件与 pkg-config 文件、gir1.2-arrow-1.0.install装 GObject Introspection typelib。从 control.in 可以看到当前版本17.x生成的库包名形如libarrow1700、libarrow-acero1700、libarrow-flight1700等——SO 版本号直接由主版本 × 100 次版本计算RPM spec 中的so_version定义同理。容器内构建脚本apt/build.sh 是容器入口核心流程加载/host/env.sh由apt_build写入的PACKAGE、VERSION通过lsb_release识别发行版Debian 用main组件、Ubuntu 用universe组件启用 ccacheCCACHE_MAXSIZE500M、CCACHE_COMPRESS6加速重复构建把源码包复制为${PACKAGE}_${VERSION}.orig.tar.gz并解压处理~dev/~rc版本的目录名差异按目标平台选择debian.platform-arch、debian.platform或默认debian目录作为打包元数据执行debuild -us -uc默认输出重定向到/dev/nullDEBUGyes时显示全部日志把产物复制到宿主挂载的仓库目录repositories/发行版/pool/code_name/component/包名首字母/包名/。仓库目录与测试构建完成后可用rake apt:test实现在 dev/release/binary-task.rb做端到端验证合并各包的apt/repositories用apt-dists-merge生成 dists 索引然后对每个目标发行版实际执行apt-get install验证依赖与安装正确性。YUM.rpm构建链路spec 模板RPM 侧的元数据核心是 arrow.spec.in。yum_build在构建前会用substitute_content把PACKAGE、VERSION、RELEASE替换为实际值生成apache-arrow.spec。该 spec 文件信息量很大值得关注的要点Name被设为arrowrpm 包名见rpm_package arrow而 deb 包名是apache-arrow同一版本在两套体系下的包名约定不同so_version major*100 minor用于生成arrow1700-libs、gandiva1700-libs、parquet1700-libs等运行时包名通过%if %{_rhel} 8、%{_amzn} 2023等宏按发行版条件开启 Flight、Gandiva、mimalloc、gcs 等组件如%define use_flight (%{_rhel} 8 || %{_amzn} 2023)CentOS 7 特殊处理使用devtoolset-11-gcc、cmake3并通过vault.centos.org指向归档源见 centos-7/Dockerfile 中的仓库重定向%build阶段与 deb 的 rules 等价先在cpp/下用 CMake 构建-DARROW_PACKAGE_KINDrpm开启 CSV/Dataset/JSON/ORC/Parquet 及压缩编解码支持再在c_glib/下用 meson 构建并安装产出约 30 个子包运行时库arrow1700-libs、工具arrow-tools、开发包arrow-devel、各模块的-libs/-devel/-doc以及 GLib 系的arrow-glib-*、gandiva-glib-*、parquet-glib-*等。容器内构建脚本yum/build.sh 与 apt 版对称加载/host/env.sh含SOURCE_ARCHIVE、PACKAGE、VERSION、RELEASE从/etc/system-release-cpe解析发行版名与版本区分 Amazon Linux、CentOS Stream 等特例并识别架构i386时库目录切换为/usr/lib初始化 rpmbuild 目录树rpmdev-setuptree或手工创建 SOURCES/SPECS/BUILD/RPMS/SRPMSdev 版本时对源码包做--transform重命名后重新打包再复制 spec 到rpmbuild/SPECS/执行rpmbuild -ba默认静默DEBUGyes时显示日志CentOS 7 等场景通过SCL启用 Software Collections 环境把 RPM 产物移动到repositories/发行版/版本/架构/Packages/SRPM 放到repositories/发行版/版本/source/SRPMS/。测试侧rake yum:testbinary-task.rb会对 RPM 签名rpm_sign、生成 yum 仓库元数据并在各目标发行版上实际执行安装验证。两个仓库辅助包apt-source 与 release为了让最终用户能便捷地把 Apache Arrow 官方仓库接入包管理器仓库额外维护了两个安装辅助包apache-arrow-apt-sourceapache-arrow-apt-source/Rakefile下载 Apache 的 GPGKEYS文件打包生成的apache-arrow-apt-sourcedeb 包在安装时把 Arrow 仓库密钥装入系统见 control替换旧的apache-arrow-archive-keyring包。该包只走 APT 流程enable_yum? false。apache-arrow-releaseapache-arrow-release/Rakefile把 Apache-Arrow.repo内含 almalinux、amazon-linux、centos、rhel 的仓库定义与过滤后的 GPG KEYS 打包成 RPM。KEYS 过滤逻辑会剔除rpmkeys --import报错的 ED25519 等密钥见 Rakefile 中的 deny_lists。该包只走 YUM 流程enable_apt? false。这两个包的存在使得官方安装文档中的一条命令接入仓库成为可能而它们本身也由同一套 Rake/Docker 流水线产出保持了打包体系的一致性。CI 自动化GitHub Actions 模板虽然 README 只讲了本地命令仓库还提供了完整的 CI 模板 github.linux.yml并被 dev/tasks/tasks.yml 展开为每个发行版 × 架构的独立 jobamd64 使用ubuntu-22.04runnerarm64 使用自托管 runner并设置ARCHERY_USE_DOCKER_CLI控制是否走 docker CLI流程依次为安装 Ruby/rake → 为 arm64 准备apt/yum目标目录 →rake version:update→rake docker:pull容错→rake {apt|yum}:build BUILD_DIRbuild通过APT_TARGETS/YUM_TARGETS/ARROW_VERSION/REPO环境变量注入参数→rake docker:push复用镜像 → 生成测试 GPG 密钥 →rake {apt|yum}:test实际安装验证最终把repositories/**下的产物apt 的.deb/.dsc/.orig.tar.gzyum 的.rpm上传为发布资产。这意味着 README 中的两条本地命令在 CI 中就是以同样的 Rake 任务为核心、配合环境变量与容器缓存规模化执行的。常用环境变量速查变量作用默认值 / 说明ARROW_VERSION指定打包版本缺省时从java/pom.xml读取并生成-devYYYYMMDDARROW_RELEASE_TIME指定发布/打包时间RFC 3339缺省取仓库最近一次 git commit 时间APT_TARGETS/YUM_TARGETS覆盖目标发行版列表逗号分隔各有一套内置默认列表REPODocker 镜像仓库前缀缺省从仓库根目录.env读取BUILD_DIR指定容器外编译工作区持久化 ccache可选DEBUGyes时输出完整构建日志默认no静默构建DEB_BUILD_OPTIONS透传给 debuild 的选项如parallel8可选RPM_BUILD_NCPUS透传给 rpmbuild 的并行核数可选DEB_RELEASE覆盖 deb 的 Debian 修订号1DEBFULLNAME/DEBEMAIL/NAME/EMAIL生成 changelog/spec 时使用的打包者信息缺省从 git config 推断总结dev/tasks/linux-packages/用约五个 Rake 项目加两个build.sh脚本把 Apache Arrow C/GLib 的多发行版打包问题收敛为rake version:updaterake apt/rake yum两个动作。其核心价值在于统一的版本三态映射dev/rc/release、Docker 隔离的可复现构建、按发行版条件化裁剪的依赖与组件开关control.in模板、spec 宏以及完整的仓库目录产出与 CI 测试闭环。无论是想要在本地复刻官方软件包还是把类似流程移植到自己的多发行版项目中这套文件都是可直接参考的完整范例。【免费下载链接】arrowApache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing项目地址: https://gitcode.com/gh_mirrors/arrow13/arrow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
