Arch Linux CN 开发入坑指北

嘿,同学,你知道 Arch Linux 吗?

优秀的开发者是不需要睡觉的

我,艾雨寒(化名),24岁未到,是学生。每日生活十分规律,AOSC 社区认证 UTC+8 生物钟。在我还是一个普通 Arch 用户的时候,每天除了上课偶尔打打瞌睡,玩玩手机之后,似乎也没有什么与其他同学不同的地方,唯一的习惯就是喜欢每天关机之前滚包。加入 Arch Linux CN 不到三个月,通过每天的努力,头发变长,体重渐增,喜提艾老师称呼一枚。尽管现在晚上睡得越来越晚,但是我还是尽量保证 UTC+8 的生物钟起床,睡眠时间的减少,让我的人生越发充实。同时也意识到,开发者本身也是闲时劳动,义务开发,这一点对于诸多发行版来说都是一样的。

上面以我自己的例子引出了两个想表达的点。一方面:用户与开发者在个人权益上是对等的,开发者可以出于责任心进行维护,也可以发扬”开源精神”: you can you up;另一方面:其实开发者与用户之间并没有鸿沟。意识到这两点,是融入开源文化的第一步,无论是对用户还是对于开发者来说。

我怎么就管不住这手

下一步是如何判断自己是否适合、或者想要成为开发者,人们往往难以直接寻找到内心的答案,就好比别人问你喜欢某个某个谁,你可能一时半会儿答不出来,但是如果让你和某个人坐同桌,你一下子就能反应过来自己是不是愿意和某个人同桌。不扯到心理学的潜意识自画像和心理学侧写了,简单起见以我自己为例,上面的一段话中我提到了我喜欢经常滚包,时不时顺手就来一个,实际上这就是一种潜意识反应,暗示我需要新的东西,我渴望新的东西,并且我为此等得很难受。那么对于 Arch 用户来说这就是一个成为开发者很好的契机。或者说我讨厌自己系统出问题的时候总是要等开发者有空,或感觉自己被凉到一边,或感觉总是麻烦别人不太好,那么这也是一种想要成为开发者的潜在诉求。如果你也有一样或者类似的经历,那么你可以进一步考虑成为开发者。

Linux 发行版:“强迫症患者”们的共识社区

同性交友社区

说到这里就不得不提社区文化了,各位老师技术过硬,打包又劲,说话特好听,我超喜欢这里的!!!(x 实际上如果细心观察的话,Arch 的开发者或者长期用户似乎总是喜欢“多管闲事”,不仅管自己发行版的事情,也喜欢在其他发行版社群解决问题。这是社区文化文化所带来的,其实有很多人不理解为什么一个发行版要把安装过程搞得这么复杂,而且坚决不妥协。实际上这就是一个强迫用户主动学习的过程,用户在使用的过程中就会得到成长,而折腾得多了,自然就久病成医,所以实际上多数开发者最开始也就是普通用户,在一次次的折腾中不断提升。而实际上整个社区分工也是这样,并没有复杂的等级关系,能者胜任。最简单的就是 AUR Maintainer,这一层主要是用户初步满足自己的需求。而往上是社区的维护者,比如 Arch CN,主要从事一些将 AUR 中优秀的包审核并移交到社区源,对于不够优秀的包进行建议和修正以及处理各种请求等。再往上分为 TU(Trusted User) 和 Dev,前者是负责将社区源中优秀的包移交到官方社区源,相当于再次遴选,目前 Arch CN 社区内有肥猫和 fc 老师两名 TU,而肥猫同时也是 Dev (为劳模鼓掌!)。而后者则是针对系统底层构建和内核 BUG 进行处理的开发者。并没有复杂的分组和指派,这意味着你可以佛系打包,选择自己感兴趣的来做。也正因为这种没有明显分工的形式,在你遇到问题的时候,其他开发者也能够帮助你或者共同探讨解决的办法,而不是事不关己高高挂起。当然既然选择了维护某个包,责任感还是要有的,将♂心♂比♂心,赤♂诚♂相♂待。

什么,原来已经 8102 年了

有足够的时间和精力来维护自己所要维护的包

那么既然提到打包了,那么打包有多难呢?实际上之前有一些人也因为看到 Arch CN 申请当维护者中的第一条就望而却步了。我是学生,有繁重的学业任务,无法保证足够的时间和精力,又或者我需要上班,忙于生计也没有足够的时间。但是如果细心的可以看一下这个要求至少是两年之前的了,现在的打包更新主要依靠 Lilac 这个 bot 来实现,自动化程度提高,包更新和打包几乎无需人工处理,打包门槛降低但包的质量反而有所提升,用 AOSC Jeff Bai 的一句话来说:“那边的人类已经灭亡了”,因为开发者的主要工作就是一次性的复制粘贴和检查依赖,去其他群闲聊吹水,偷偷传教,普度众生,突然发车。(后面这些我瞎说的)。正因如此,申请本身并不复杂,门槛也不高。你只需要发送一些必要信息到社群邮箱即可,如果你不用公用服务器打包的话你可以不提交 ssh pubkey,而如果只用 Lilac 打包的话你甚至不需要提供 GPG 公钥,因为机器人会自动签名。(当然最好是都提供)

申请当维护者 · archlinuxcn/repo Wiki · GitHub

紫丁香栽培技术

GitHub - archlinuxcn/lilac: Lilac is the build bot for archlinuxcn

Lilac 是 Arch CN 目前主要的打包机器人,主要由百合负责开发(@lilydjwg),本来算是一个挺有诗意的名字,但是好像放在社区内就成了基佬紫的代名词(逃得飞快)。

Lilac 通过社区仓库来获得打包信息并使用爬虫定时检查更新。这就要求在向仓库提交改动之前建议先本地使用构建工具测试一次,具体流程如下:

  • 强烈建议开发者打开testingcommunity-testing源,这可能会带来一些问题,但是可以避免更多人出现问题。
  • 安装devtoolsdevtools-cn-git并安装base-devel包组,之后就有了extra-x86_64-buildarchlinuxcn-x86_64-build这两个构建工具。不同于makepkg一把梭,它们能够自动构建出一个容器,也就是一个干净的打包环境,避免出现不必要的依赖,也即避免打出脏包,具体实现可以查看 wiki 的 systemd-nspawn页面。并且对包和 PKGBUILD 文件自动检查。
  • 在包所在目录下执行extra-x86_64-buildarchlinuxcn-x86_64-build,如果有手动修改包更新的话先执行updpkgsums以更新 hash 检查值。这两个工具的区别在于前者是没有archlinuxcn这个源的,这意味着它并不能直接将 archlinuxcn 的包作为依赖打进去,而后者可以。
  • 检查输出的打包日志没有问题之后清理本地环境,比如包和日志,还有各种隐藏文件,比如 .gitignore。然后在 archlinuxcn/repo 中创建同包名文件夹,并将内容复制进去,然后提交。
  • 添加 lilac.py 和修改 nvchecker.ini 文件,这二者主要是用于配置打包环境和更新触发条件的。比如我要打一个 AUR 的包,触发条件为 AUR 更新的时候就自动更新包,那么就可以这样写 lilac.py 文件:

    1
    2
    3
    4
    5
    6
    7
    8
    from lilaclib import *

    build_prefix = 'extra-x86_64'
    pre_build = aur_pre_build
    post_build = aur_post_build

    if __name__ == '__main__':
    single_main()

    并且在 nvchecker.ini 上添加开发者信息、包名和包源:

    1
    2
    3
    # Ariel AxionL <[email protected]> {{{1
    [package-name]
    aur =

    更多模板和说明在GitHub - lilydjwg/nvchecker

  • 检查邮件。一般从提交到打包等待的时间不会超过八个小时,如果打包失败的话 CI 会向你发送失败相关的信息,以及打包的 log,根据问题进行修改或者向其他开发者反馈。

这里小提示一下,因为目前devtools提供的工具还没有实现多实例并行打包(实际上也就是单个容器反复使用),所以在一个包正在打包的情况下,开另一个打包事件会提示占用,需要等待上一打包的完成。不过好在目前有多台打包机器,影响不大。但是还是要注意大型包比如 chromium-dev(编译打包时间大约为两个小时)尽量在闲时进行。而如果是小型包的话在本地测试的时候可以灵活切换使用 makepkgextra-x86_64-build,具体优化配置可以看 makepkg - ArchWiki

放低“樽盐”,好好做嘢

社区准则我也看了,打包流程我也学会了,那么关键问题来了:如何打包呢?

开头说了,开发者本质上也是用户,而一切打包都得从 Arch User Repository 也即 AUR 说起。这里指的不仅仅是熟悉 PKGBUILD 或者 Pacman。有人说 Arch Linux 的精髓来源于 AUR 也体现于 AUR,任何包的构建文件就摆在那,自由提交,真实投票,在线打包(划掉x,没有广告的意思)。包括社区源也是一样,如果在 archlinuxcn/repo 没有提交包的构建文件,即便是手动打包上传到源里也会自动删掉。而如果你要打包某个新软件,最好先去 AUR 挖个坑。如果某个软件包的 AUR 有问题导致无法打包失败,也尽量去找 AUR Maintainer 反馈或者找上游解决。这一点与多数其他发行版不同,把发行版部分交给用户处理,开发者征求用户意见并提出改进建议,而不只是由开发者内部自行解决。

这里有个处理 AUR 与源关系的例子 ,除非包是 -git,不然一般以 AUR 为准
firefox-kde-opensuse out of date · Issue #724 · archlinuxcn/repo · GitHub

终了?

最后,欢迎更多用户加入 Arch CN 开发者行列!

完结撒花!~文笔不好,还请见谅 QwQ

申请当维护者 · archlinuxcn/repo Wiki · GitHub

如果关于本文有更多建议或者反馈的话可以联系我 https://t.me/ArielAxionL