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

白嫖真香!

前言

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

我看了看,觉得是好的,因为在本地编译 AUR 包的体验并不好:

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

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

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

于是我又自己整了一个项目: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。或者你也可以手动触发,然后就能坐等打包结果了。