Arch Linux 社区中不成文的约定（一）

作为一个年轻和小众的社区（咳咳），Arch Linux 社区中有着许多不成文的约定。本文希望通过稍稍讲解一二，来消除一些新人们常常感到的困惑。由于预感到日后可能还会有更多问题，暂且认为这是系列里的第一篇 😛

• 修理“坏”包和提醒更新

仓库里一般的包可能有一个或多个维护者，也可能没有维护者，成为“孤儿”。如果坏掉或者过期的包是一个孤儿，申请从仓库里删掉是更有效的方法，这样它可以在 AUR 找到新的主人。发邮件到 aur-general 解释一下情况，并表明自己或者别人想维护它，一般都会很快得到解决。

如果“坏”包有维护者，但他太忙了呢？这种情况下，这个包很可能已经在 Bug Tracker 里泥足深陷。这种时候可以通过帮维护者一个小忙的方式来促进问题的解决。如果有人找到了上游 Bug Report，并且上游已经修复提供了 patch 的话，可以考虑把 patch 贴到 Arch 的 Bug Tracker；如果这件事已经有人做了，可以修改 PKGBUILD 打上 patch，然后把改好的 PKGBUILD 贴上去；如果连 PKGBUILD 都有人准备好了，而且过去了一段时间的话，可以考虑把这份准备好的 srcpkg 或者 diff 直接发邮件给维护者，附上简短的感谢和一个笑脸 🙂

同样的道理，如果一个过期包已经被标记过期很久了，也可以准备一个新版的 PKGBUILD 发邮件给维护者。

• 提供旧版软件包

因为懒得迁移各种各样的原因，你可能希望某些软件包的新旧版本同时提供。在 Arch 的实践中，这种情况被尽量避免了。把无法迁移的古老软件删掉还是提供一个旧版库让古老的软件能用，一定程度上取决于维护者对这个古老的软件有多坚持。

另一个考虑的因素是上游如何看待新旧版本。有的软件新版发布后，旧版就不再维护了，这种情况下 Arch 通常尽力避免成为新的上游。而有的上游则同时维护多个版本，Arch 这边根据其他软件的依赖情况，可能会有选择性地同时维护几个。

• 第三方 patch 能不能加上

Arch 对 patch 的态度比较保守，在规则里写的是一般只有修复编译和主要功能的上游已经接受的 patch 会考虑。在实践中，有些时候没有这么严格，比如我开发者自己写的 patch 一边提交给上游，还没等答复，一边就加到了包里。因为 Arch 打包并没有 Review 过程，实际上加了什么 patch、靠不靠谱就全靠开发者自己掂量了。

一般来说，被上游明确拒绝的功能性 patch 是不怎么会考虑的。修复一个特定问题，尤其是影响比较大的问题的上游有点意见的 patch 有可能会被考虑。修复一个安全问题的 patch 经常会被接受，尤其是已经拿到 CVE 号的。

• 使用上游二进制 vs 从源码编译

一般常识是发行版们倾向于从源码编译一个软件，理由包括确保二进制真的来自这份源码、尽量使用系统中的动态链接库而不是静态编译一份以满足安全更新和体积方面的考虑、进行必要的修改等。

但是因为太懒一些问题，即使是在 Arch 官方仓库里也直接重新打包了一些上游的二进制。这些问题包括：源代码不开放（nvidia、flash 等）、编译过程中会去下载东西，而且不容易解决（dart、一些 java 软件等）。

• 文档是否打包

现在互联网十分发达，开发者们查询文档通常都是直接上网搜索。在这样的背景下，是否打包软件包的文档（通常都是开发文档）成为了一个问题。早些时候的包开启文档较多，如果太占体积还会考虑拆一个单独的文档包。后来才增加的新包则很多都没有启用文档，除非被用户要求提供文档才考虑这件事。