Arch 用户当然要有自己的软件源！

白嫖真香！

前言

起因是有人在群里发了一篇利用 GitHub Actions 打包 AUR 并建立本地软件源的文章。

我看了看，觉得是好的，因为在本地编译 AUR 包的体验并不咋样：

  • 需要下载大量外网的资源，尤其是打 git 包的时候因为 makepkg 不支持 shallow clone 所以不得不将整个 repo 拉下，下载几百兆的东西最后打出一个两三兆的包是常有的事。
  • 某些包真的是很难编译，从几十分钟到数小时，感觉自己都变成 Gentoo 用户了……

这篇文章给了我很大的启发，但是文章中的方法并不能满足我的需求：

  • 我需要打的包还依赖了其它的 AUR 包，所以仅仅 makepkg 是不够的，我需要一个完整的 AUR Helper。
  • 我需要对部分包的 PKGBUILD 进行修改
  • 我还想重打某些官方源里的包
  • 本地源不够好用，我想直接建立一个个人源。

于是我又自己整了一个项目：https://github.com/Aloxaf/aur-build

效果如下：https://repo.aloxaf.com/

使用方法，将下列文本追加到 /etc/pacman.conf 中，

1
2

[aloxaf]
Server = http://repo.aloxaf.com/$arch

然后执行下列命令导入我的 GPG 公钥

1
2

sudo pacman-key --recv-keys A07920B86500DE6C
sudo pacman-key --lsign-keys A07920B86500DE6C

就可以愉快地使用了。

过程中踩的各种坑就不说了反正你们也不想听，直接说用法吧。

准备工作

服务器 x 1

用来建立你的个人源，以及存放加密后的构建脚本。

服务器上只用装好 nginx ，打开 autoindex 并启动即可，你很懒的话直接跑一个 simple-http-server 甚至都可以。因为全部工作都是在 GitHub Actions 上完成的，包括建源。所以理论上放到支持直链的网盘或者云存储上都行。但是我懒，既然有服务器何必闲着。

如果你打算传到云上的话可以使用 uptoc-action，上传目录为 /home/aur-build/.cache/pikaur/pkg。或者也可以像我开始介绍的那篇文章一样传到 GitHub releases 上。

SSH 密钥 x 1

用于将打好的包部署到服务器上。

由于这个密钥需要上传到 GitHub Actions 上，为了防止可能存在的泄露，建议单独生成一个：执行 ssh-keygen -f ~/.ssh/aur_build 生成密钥，然后将 ~/.ssh/aur_build.pub 中的内容追加到你服务器对应用户的 ~/.ssh/authorized_keys 文件中。

GPG 密钥 x 1

用于签名包，虽然不是必需的但是有这个显得很正规（

出于同样的理由建议生成一个单独的子密钥，没有的话参照这篇文章自己生成一个并上传到公钥服务器上。

GitHub Repo x 1

可以直接 fork 我的 Repo。然后把它 clone 到本地进行修改

配置

塞密钥

全塞到 ./script/data 目录下即可。整个脚本会被加密压缩然后传到服务器上，一般情况下不会泄露。

1
2
3
4
5
6

# 导出 GPG 私钥
gpg --export-secret-keys-subkeys YOUR_GPG_KEY_ID > ./script/data/private.key
# 还有 GPG 私钥的密码
echo -n 'YOUR_GPG_KEY_PASSPHARSE' > ./script/data/private.passpharse
# 还有你的 SSH 私钥
cp ~/.ssh/aur_build ./script/data/private.passpharse

建立 ./script/script.conf

这里存放了你的自定义配置，比如你的服务器地址，脚本的加密密码等。我提供了一个 sample 文件，照着改就行了

  • 必须要改，不然跑不起来：GPGKEY SERVER SCRIPT
  • 建议你改，虽然不改我也不能拿你怎样：REPO_NAME PACKAGER PASSWORD
  • 看自己情况决定改不改：CFLAGS CXXFLAGS，其中 -march 的值可以通过在自己电脑上执行 gcc -march=native -Q --help=target | grep march= 获得

配置 GitHub Actions Secret

在你 REPO 主页点击 Settings -> Secrets -> New secret。

添加两个 Secret

  • SCRIPT_URL：你的构建脚本的下载地址
  • PASSWORD：构建脚本的密码（就是上一节的 PASSWORD）

放入你想要打包的包

在 ./script/packages 下建立对应目录，根据目录内容的不同有三种包：

  1. 目录为空，则为普通的 AUR 包，构建时会去 AUR 上寻找同名包。
  2. 目录下有一个 PKGBUILD，则直接用这个 PKGBUILD 打包。
  3. 目录下有一个 build.zsh，则执行这个 build.zsh 打包

绝大多数情况下都是第一种。

打包上传你的构建脚本

运行 ./script/upload_script.zsh ，构建脚本会被压缩加密并上传到服务器上。然后 GitHub Actions 在执行时会下载这个压缩包并解密再执行里面的脚本。

什么？你问我为什么不直接 push 到 GitHub 上，而要多此一举呢？

其实是为了方便，采用这种方式构建的话，不用每次修改文件都重新 push 一次，只要重新触发 workflow 就行了，尤其是初期测试的时候常常改来改去……这个方法为我省下了大量无意义的 commit。

测试

Push 到 GitHub 上，以触发 GitHub Actions。或者你也可以手动触发，然后就能坐等打包结果了。