如何把 AppFlowy 的 Linux 构建产物打包成 .deb 安装包-二趣网

如何把 AppFlowy 的 Linux 构建产物打包成 .deb 安装包

【免费下载链接】AppFlowyBring projects, wikis, and teams together with AI. AppFlowy is the AI collaborative workspace where you achieve more without losing control of your data. The leading open source Notion alternative.项目地址: https://gitcode.com/GitHub_Trending/ap/AppFlowy

如果你的 AppFlowy Linux 版本 release 构建已经完成，想把Release产物目录里的应用打包成可以在 Debian 系系统上安装的.deb文件，仓库自带了现成的打包脚本。整个流程只需要一台能运行dpkg-deb的 Linux 主机和一份已构建好的 Linux release 产物，产物生成后位于你传入的 release 路径下，文件名由你指定。

前提条件

根据 deb 打包说明，打包前需要满足两点：

系统中可用dpkg-deb命令；
应用已经为 Linux 完成构建，产物位于frontend/appflowy_flutter/下的 release 目录中，目录内包含名为AppFlowy的应用目录。

关于产物路径，文档中存在一处不一致：README 的 Prerequisites 一写的是frontend/appflowy_flutter/production/$VERSION/linux/Release/，而同一文档的示例命令和实际构建逻辑用的都是product目录。实际构建任务 copy-to-product-linux 的输出路径是appflowy_flutter/product/${APP_VERSION}/linux/Release/，即product目录，下文按product路径执行。

如果你还没有 Linux release 产物，仓库的发布构建入口在 tool.dart 中给出的命令是：

cargo make --env APP_VERSION=0.2.9 --profile production-linux-x86_64 appflowy

其中0.2.9需要替换成你的目标版本，APP_VERSION决定产物输出到product/下的哪个版本目录。production-linux-x86_64profile（见 frontend/Makefile.toml）会把 Rust 侧以 release 模式编译为x86_64-unknown-linux-gnu目标，Flutter 侧以Release模式构建，并执行flutter build linux --release。如果不传APP_VERSION，set-app-version 任务会回退使用frontend/Makefile.toml中 [env] 段的APPFLOWY_VERSION（当前仓库中为0.11.4）。在 Docker 中构建时，Dockerfile 额外设置了OPENSSL_STATIC=1、ZSTD_SYS_USE_PKG_CONFIG=1、ROCKSDB_LIB_DIR="/usr/lib/"这些环境变量，本地直接构建可忽略。

执行打包脚本

进入frontend/目录后，运行 build_deb.sh，传入三个参数：release 产物路径、版本号、.deb文件名：

cd frontend/ sh scripts/linux_distribution/deb/build_deb.sh [LINUX_PRODUCTION_RELEASE_PATH] [VERSION] [PACKAGE_NAME]

文档给出的示例（路径与文件名需替换为你自己的版本）：

sh scripts/linux_distribution/deb/build_deb.sh appflowy_flutter/product/0.2.9/linux/Release 0.2.9 AppFlowy_0.2.9.deb

三个参数的含义：

LINUX_PRODUCTION_RELEASE_PATH：.../product/$VERSION/linux/Release这一层目录，脚本会在其中找到AppFlowy应用目录，并在该目录内新建package暂存目录；
VERSION：版本号，用于填充 deb 控制文件；
PACKAGE_NAME：最终.deb文件名，输出位置就是LINUX_PRODUCTION_RELEASE_PATH之下。

注意脚本会对 release 目录产生写入：在$LINUX_PRODUCTION_RELEASE_PATH下创建package子目录及其中的usr/、DEBIAN结构。重复执行时旧的package内容会被再次拷贝覆盖，最终产物则以新的dpkg-deb构建结果为准。

脚本内部做了什么

了解脚本行为有助于排错，build_deb.sh 的流程是：

在 release 路径下创建package/DEBIAN、package/usr/lib、package/usr/share/applications、package/usr/share/icons/hicolor/scalable/apps、package/usr/share/metainfo等目录；
把 DEBIAN 控制文件目录复制进包，把postinst、postrm权限设为0755，并将control文件中的[CHANGE_THIS]占位符替换为第 2 个参数传入的VERSION；
把$LINUX_PRODUCTION_RELEASE_PATH/AppFlowy整个拷贝到usr/lib，同时放入 AppFlowy.desktop 桌面入口、io.appflowy.AppFlowy.metainfo.xml元信息和appflowy.svg图标；
执行最终构建：

dpkg-deb --build --root-owner-group -Z xz $PACKAGE $LINUX_RELEASE_PRODUCTION/$PACKAGE_NAME

其中--root-owner-group表示包内文件以 root 为属主，-Z xz指定 xz 压缩。

control文件中固定了打包元数据：包名AppFlowy、架构amd64、依赖Depends: libkeybinder-3.0-0（见 DEBIAN/control）。也就是说该.deb面向 amd64 的 Debian 系系统，且安装时要求目标系统装有libkeybinder-3.0-0库。

安装到目标机器时的行为也由脚本目录中的文件决定：postinst 在/usr/bin下创建两个符号链接——/usr/bin/AppFlowy指向/usr/lib/AppFlowy/AppFlowy，/usr/bin/AppFlowyLauncher.sh指向/usr/lib/AppFlowy/launcher.sh（已存在则跳过）；postrm 在卸载时删除这两个链接。桌面入口的Exec=/usr/bin/AppFlowy %U和图标路径/usr/share/icons/hicolor/scalable/apps/appflowy.svg均指向包内安装后的位置。

验证打包结果

README 给出的成功判定是：.deb文件生成在[LINUX_PRODUCTION_RELEASE_PATH]/[PACKAGE_NAME]，也就是上例中的appflowy_flutter/product/0.2.9/linux/Release/AppFlowy_0.2.9.deb。构建成功时dpkg-deb --build会输出构建该包的提示；如果失败，通常是缺少dpkg-deb命令、release 路径里找不到AppFlowy目录，或VERSION参数与产物目录中的实际版本不一致。

限制说明

该包只覆盖 amd64 架构（control中Architecture: amd64），aarch64 Linux 产物不能直接套用这条路径；
VERSION参数必须真实存在，脚本只负责把它替换进control，不会校验它与产物是否一致；
打包脚本只负责生成.deb，目标机器上的安装（需要 root 权限写入/usr/lib和/usr/bin）不在仓库文档范围内。

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

企业官网建设流程全解析