OpenHuman Arch Linux AUR 打包实战openhuman-bin 二进制包的构建、测试与发布指南【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 是一款面向 Mac、Windows 与 Linux 的开源本地优先个人 AI 桌面应用。对于 Arch 系发行版用户官方仓库在packages/arch/openhuman-bin下维护了一份 AUR 二进制包配方openhuman-bin它不直接运行官方 AppImage 的运行时而是提取应用树后通过/usr/bin/openhuman启动器直连内部二进制。读完本文你将掌握该 AUR 包的完整设计动机、PKGBUILD的逐段语义、本地构建与校验流程以及每次发版时从pkgver到.SRCINFO的完整升级操作。背景Linux 发布形态与 AUR 包定位OpenHuman 的桌面端采用 Tauri 2 构建其打包配置app/src-tauri/tauri.conf.json中声明了appimage、deb、dmg、nsis、msi等发布目标在 Linux 平台上官方会同时产出.deb包和 amd64 的 AppImage 工件。openhuman-bin的定位是二进制包-bin后缀它不从源码编译而是把官方发布到 GitHub Releases 的 x86_64 AppImage 当作二进制来源在makepkg阶段就地解包、提取应用树再安装桌面条目desktop entry与/usr/bin/openhuman启动器。官方文档 INSTALL.md 明确建议 Arch 用户在包发布后通过yay -S openhuman-bin安装gitbooks/developing/getting-set-up.md 也给出了本地构建的等价命令。核心设计决策为什么不直接启动 AppImage 运行时这是该 AUR 包最关键的工程决策值得先讲清楚。普通的-bin包往往直接下载.AppImage、赋予可执行权限然后原样运行但openhuman-bin刻意绕开了 AppImage 运行时The package does not launch the AppImage runtime directly. Arch-family distros have reportedInterpreter not found!from the bundled AppImage runtime on v0.54.0.也就是说在 v0.54.0 时代Arch 系发行版用户直接运行该 AppImage 时内置运行时sharun 风格的AppRun会报出Interpreter not found!——这是动态加载器/解释器路径在滚动发行版环境下解析失败的表现。作为佐证仓库的发布修复计划 docs/plans/2026-07-24-appimage-sharun-lib-path.md 在测试夹具里就用printf Interpreter not found! $appdir/sharun来模拟这一故障形态可见该错误确属 sharun 启动器链路的历史已知问题。因此openhuman-bin的启动器并不调用 AppImage 运行时而是在prepare()阶段用--appimage-extract解开 AppImage得到squashfs-root/应用树安装期把整个应用树复制到/opt/openhuman由/usr/bin/openhuman这个 bash 启动器直接执行应用树内的shared/bin/OpenHuman原生二进制并显式把捆绑库目录加入LD_LIBRARY_PATH。这样既享受了 AppImage 自包含的应用树含 CEF 等重型依赖又规避了运行时解释器在滚动发行版上的兼容性问题。PKGBUILD 逐段拆解完整的配方见 packages/arch/openhuman-bin/PKGBUILD。下面按段说明其语义。包元数据pkgnameopenhuman-bin pkgver0.54.0 pkgrel1 pkgdescPersonal AI desktop assistant for communities arch(x86_64) urlhttps://github.com/tinyhumansai/openhuman license(GPL-3.0-only) provides(openhuman) conflicts(openhuman) options(!strip)pkgver0.54.0当前配方固定追踪的稳定版本号不含前导v发布标签才带v例如v0.54.0。注意仓库主线tauri.conf.json的版本可能已领先于 AUR 配方发布前必须按下文版本升级流程同步。arch(x86_64)仅面向 x86_64 架构因为二进制来源是官方 amd64 AppImage。provides/conflicts声明本包提供并冲突于openhuman这个虚拟名避免与同名源码包或手装版本共存。options(!strip)禁用 makepkg 的二进制剥离——应用树内捆绑的 CEF 等共享库需要保留原始符号与重定位信息强行 strip 可能破坏运行。可选依赖optdependsoptdepends( xdg-utils: open browser, file, and URL handlers from the desktop app libsecret: Secret Service credential storage on some Linux desktops fuse2: run the downloaded AppImage directly outside this package )三个可选依赖各司其职xdg-utils桌面应用需要通过xdg-open等工具唤起浏览器、文件与 URL handlerlibsecret部分 Linux 桌面环境下 Secret Service 凭据存储的依赖对应 OpenHuman 的密钥/凭据持久化能力仓库中src/core有独立的 keyring/secret-store 实现但桌面侧仍可能回落到 libsecretfuse2仅供包外直接运行下载的 AppImage这一场景使用——即用户想绕过本包启动器、手动执行原始.AppImage时才需要 FUSE 挂载本包自身安装与运行不依赖它。source 与校验和source( OpenHuman_${pkgver}_amd64.AppImage::https://github.com/tinyhumansai/openhuman/releases/download/v${pkgver}/OpenHuman_${pkgver}_amd64.AppImage openhuman openhuman.desktop openhuman.svg ) sha256sums( 2f76bc5b6f3a0e6cf2765f414a82b26903337720d190b4f9b26a5d7e2508abab dbd46b85be9d551363b44ec19613a5fb5df4a08f5b618cb38ffe8891a0f31eeb e357a666334449273047c02740a3e3fa34c58ff00304af8b3ec1a080a9574e99 7892979a084a5e2bbc73c32fe0f447918aa9b458c50bf0bb856469c837e6401c )远程源使用::语法把下载文件重命名为OpenHuman_${pkgver}_amd64.AppImageURL 指向 GitHub Releases 的v${pkgver}标签本地源共三个启动器openhuman、桌面条目openhuman.desktop、可缩放图标openhuman.svg四个sha256sums与 source 一一对应。发布升级时必须同时更新 AppImage 与启动器的校验和makepkg 会在构建前严格比对一旦失配立即中止。prepare()解包并断言应用树完整prepare() { cd ${srcdir} rm -rf squashfs-root chmod x OpenHuman_${pkgver}_amd64.AppImage ./OpenHuman_${pkgver}_amd64.AppImage --appimage-extract /dev/null test -x squashfs-root/shared/bin/OpenHuman }先清理可能残留的squashfs-root保证解包结果干净chmod x后调用 AppImage 自身的--appimage-extract原地解包——注意这一步并不依赖 FUSE也不触发运行时解释器因此规避了前文提到的Interpreter not found!最后的test -x squashfs-root/shared/bin/OpenHuman是fail-closed 断言若官方 AppImage 的应用树布局发生变化比如不再存在shared/bin/OpenHuman构建会在早期失败而不是把坏包装进系统。package()安装布局package() { install -d ${pkgdir}/opt/openhuman cp -a --no-preserveownership ${srcdir}/squashfs-root/. \ ${pkgdir}/opt/openhuman/ install -Dm755 ${srcdir}/openhuman \ ${pkgdir}/usr/bin/openhuman install -Dm644 ${srcdir}/openhuman.desktop \ ${pkgdir}/usr/share/applications/openhuman.desktop install -Dm644 ${srcdir}/openhuman.svg \ ${pkgdir}/usr/share/icons/hicolor/scalable/apps/openhuman.svg }安装布局非常清晰目标路径内容权限/opt/openhuman/解包后的完整应用树含shared/bin、shared/lib等递归复制--no-preserveownership避免保留构建机属主/usr/bin/openhumanbash 启动器脚本755/usr/share/applications/openhuman.desktop桌面条目644/usr/share/icons/hicolor/scalable/apps/openhuman.svg可缩放图标HiDPI 友好644启动器 openhuman接管解释器与库路径packages/arch/openhuman-bin/openhuman 全文仅 8 行却是整包正确运行的关键#!/usr/bin/env bash set -euo pipefail appdir/opt/openhuman export SHARUN_LDNAME${SHARUN_LDNAME:-ld-linux-x86-64.so.2} export LD_LIBRARY_PATH${appdir}/shared/lib${LD_LIBRARY_PATH::${LD_LIBRARY_PATH}} exec ${appdir}/shared/bin/OpenHuman $逐行解读set -euo pipefail任何命令失败、未定义变量或管道中断都会立刻让启动器非零退出避免静默吞错SHARUN_LDNAMEsharun 运行时约定的动态加载器名环境变量。启动器为其提供默认值ld-linux-x86-64.so.2glibc x86_64 的标准解释器名同时允许用户通过环境变量覆盖——这正是在不依赖 sharun 的AppRun外壳的情况下从应用侧补齐解释器解析语义LD_LIBRARY_PATH把 AppImage 自带的捆绑库目录/opt/openhuman/shared/lib前置到既有库搜索路径之前${LD_LIBRARY_PATH::...}保证空值时不产生孤立冒号。这样shared/bin/OpenHuman启动时优先命中自带的 CEF、依赖库避免与宿主系统同名库版本错配最后exec直接替换为原生二进制进程并把命令行参数$原样透传因此openhuman --flag与桌面环境通过%U传入的文件/URL 参数都能生效。从源码佐证看shared/lib正是 sharun 契约中生成lib.path的规范库目录发布修复计划 docs/plans/2026-07-24-appimage-sharun-lib-path.md 确认了shared/lib/lib.path中以标记 AppDir 库根、以/subdir标记其子目录的语法启动器把该目录显式写入LD_LIBRARY_PATH等效于在包层面固化了这条契约。桌面条目应用集成细节packages/arch/openhuman-bin/openhuman.desktop 提供了桌面环境集成[Desktop Entry] NameOpenHuman CommentPersonal AI desktop assistant Exec/usr/bin/openhuman %U Terminalfalse TypeApplication Iconopenhuman CategoriesUtility;Office;Network; StartupNotifytrue StartupWMClassOpenHuman MimeTypex-scheme-handler/openhuman;Exec/usr/bin/openhuman %U把文件/URL 参数交给启动器透传StartupWMClassOpenHuman让任务栏/窗口管理器能正确归组窗口MimeTypex-scheme-handler/openhuman;注册openhuman://自定义 URL scheme配合官方应用内链路使用Iconopenhuman指向安装到 hicolor 图标主题的 openhuman.svg任何桌面主题都能按名解析。本地构建与校验在 Arch Linux 主机上进入配方目录即可本地构建cd packages/arch/openhuman-bin makepkg --syncdeps --clean --cleanbuild --force参数说明--syncdeps构建前自动通过 pacman 安装缺失的构建依赖--clean构建前清理先前的工作目录与产物--cleanbuild在干净的源目录中重新开始会重新执行完整解包流程--force即使存在同名已构建包也强制覆盖重建。构建成功后不要急着装先做包级体检pacman -Qip openhuman-bin-*.pkg.tar.zstpacman -Qip会打印包的元数据名称、版本、描述、依赖、校验和、打包时间、文件清单等用于确认 pkgrel/pkgver 正确、optdepends 文案无误、安装布局符合预期。若还想快速安装到本机官方文档 gitbooks/developing/getting-set-up.md 给出的等价命令是makepkg --syncdeps --install。发版升级流程Release bumpopenhuman-bin是跟随官方稳定版节奏更新的二进制包每次新版本发布需要按 README 的四步走更新pkgver改为新的稳定版号不带前导v如0.55.0更新 AppImage 的 SHA-256 校验和从对应 GitHub Release 资产的摘要中取新的哈希替换sha256sums第一项若启动器有改动则更新其校验和openhuman启动器也在sha256sums中变更后必须同步重新生成.SRCINFO提交到 AUR 前必须让元数据与实际配方一致updpkgsums makepkg --printsrcinfo .SRCINFOupdpkgsums依据新下载的源文件自动重算并写入全部sha256sums比手抄哈希更不易出错makepkg --printsrcinfo .SRCINFO把PKGBUILD的完整元数据含依赖、源、校验和、架构渲染成 AUR 要求的.SRCINFO文件它是 AUR 网页、yay/paru等辅助工具读取包信息的唯一标准来源。最终推送到 AUR 的仓库必须且只需包含五个文件文件作用PKGBUILD构建配方本体.SRCINFOAUR 元数据由makepkg --printsrcinfo生成openhuman/usr/bin/openhuman启动器源文件openhuman.desktop桌面条目源文件openhuman.svg应用图标源文件与发布流水线的上下游关系虽然 AUR 包是下游消费方但它的设计直接受上游发布管道约束理解这点有助于排查问题AppImage 的生成与后处理官方在 Linux 构建后运行scripts/release/strip-appimage-graphics-libs.sh剔除捆绑的libGL、libdrm、libva、libssl等宿主图形/加密库使 AppImage 在运行时回落到系统版本AUR 包继承解包后的应用树同样受益于这套宿主优先策略。sharun 库路径契约上游通过scripts/release/validate-appimage-runtime.sh与测试脚本test-strip-appimage-rpaths.sh对shared/lib/lib.path做 fail-closed 校验只接受与/suffix条目并增加了解释器替换与 RPATH 修复。启动器中对SHARUN_LDNAME与LD_LIBRARY_PATH的显式接管正是对这一契约的包级兜底。已知边界发布计划明确将unbundled AUR/core 失败列为下游跟进项见 docs/plans/2026-07-24-appimage-sharun-lib-path.md即 AUR 包形态下的某些原生模块依赖属于后续单独解决的范围不应指望在本次配方中一并处理。常见问题排查要点Interpreter not found!如果你绕过启动器直接运行解包后的 AppImage仍可能触发该错误openhuman-bin已通过/usr/bin/openhuman直连shared/bin/OpenHuman绕开此路径请确认是从 PATH 启动而非手动执行 AppImage。缺失共享库确认LD_LIBRARY_PATH生效echo $LD_LIBRARY_PATH应包含/opt/openhuman/shared/lib并核实宿主是否安装了libsecret若桌面端使用 Secret Service 存储凭据。校验和不匹配updpkgsums后仍失败通常是网络下载的 AppImage 与官方资产不一致或镜像缓存过期请对照 GitHub Releases 上的实际 SHA-256。本地构建报依赖错误先执行makepkg --syncdeps若仍未满足检查是否缺少base-devel组。小结openhuman-bin是自包含二进制 宿主化启动器思路在 Arch 生态的落地样板它用--appimage-extract继承 AppImage 的应用树完整性与便携性同时以 8 行启动器显式接管解释器与库路径绕开滚动发行版上的 sharun 解释器兼容问题。对维护者而言每次发版只需围绕pkgver、校验和与.SRCINFO三个抓手执行固定流程对用户而言yay -S openhuman-bin即可获得与官方发布一致、桌面集成完整的 OpenHuman 安装体验。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考