翻译：tx-cary ([email protected])
发布：2005年4月5日
修改：2005年4月5日

摘要

Arch Linux 被人们描述成一个完美的Linux发行版。然而，一个完美的发行版往往是处于不断进化中的。这个文档将告诉你一些开发者他们正在干些什么。

写这篇文档的目的是帮助用户们了解开发者正在做的工作以及Arch Linux的发展方向。工程中的一些部分是需要注意的重要信息，另外一些是用户们也许不需要知道的改进。

内容列表

介绍

写这篇文档的目的是帮助用户们了解开发者的一些将来计划。表明开发者对一些必须表明立场的问题的立场。

现在，许多计划都是基于用户社区提出的一些要害问题，尽管开发者们都多多少少赞成其中的大部分。其它的一些新的工程的想法是开发者们为让Arch Linux更加优秀而提出的。

Arch Linux 哲学

Arch Linux背后的哲学，也是开发者遵循的原则就是“简单”。事实上，也就是“保持简单”。开发者们希望由于用复杂的方式做简单的事情浪费大量时间。 这就是为什么Arch的所有配置都是通过修改配置文件来完成的原因，也是为什么只有最新的系统被提供支持的原因。这也是下面将要提到的一些问题的最终决定的理由。

这个哲学给用户们做更多的是“能力”。你的系统是你自己的。这个Linux发行版不会帮你做什么事情，它会给你做事情的“能力”。

作为一个发行版，Arch Linux没有必要作许多事情，但是她将她需要做的事情做得很好。一个发行版的作用并不是提供软件包－－发行版所必须要提供的是一个软件包管理系统。Arch 再这方面是优秀的。她给你提供了二进包的管理工具 pacman ，也提供了源码创建软件包的 ABS。Arch提供了简单而强大的启动例程和初始化脚本。除了这些，许多的配置工作都留给了软件开发者。如果开发者开发的软件是独立运行于一个单独的目录下的话，这个软件就被放在/opt下面。如果这个软件是要被其它软件共享的，它就被放置在/usr下。这就是Arch软件包打包的方式。这样无论是对开发者还是对用户都可以保持一切简单化。如此，那些你要配置或使用到的文件被放置在程序文档中说明的地方，而不是发行版说的他们“应该”在的地方。

使用Arch的典型方法是使用pacman安装所有的软件包，除非没有这个软件包，你可以自己制作自己的软件包。我们希望你用pacman -Syu保持你的系统是最新的，而不是选择性的升级软件包。甚至在/etc/pacman.conf使用IgnorePkg也是不被推荐的。

你可能会按照你自己的方式对这种典型方式进行发挥，需要注意的是这样你的系统工作不正常的几率会高一些，也许会破坏你的系统。大部分问题都是来自选择性升级或进行了不正常的编译。

X.Org 与 XFree86

Arch Linux现在提供了两种版本的X Windows系统。标准配置正在由XFree86转向XOrg。XOrg已经进入current仓库，而XFree86仍然保留在extra。你仍然可以自由的选择你喜欢的一个版本。随着XOrg 6.8的发布，这两个X服务器开始显示出越来越大的不同。在Arch中，使用XOrg也许问题会少一些。因为XOrg的用户相对要多，发现和修复bug也要快得多。

新软件包方案

一个新的软件包方案正在开发中。这个方案曾是被讨论的焦点，现在它正被积极的开发中。一个文档描述了这个新系统的大概轮廓。

在写这篇文档的时候，新的AUR系统已经大约完成了85%。开发者们正努力的完成它。一旦它完成了，开发者们管理软件包和仓库将成为一个简单的工作，用户们向软件仓库提交新软件包也十分的简单。

Testing 仓库的作用

一些很可能会引起问题的的软件包，在他们放入官方的软件仓库之前，首先放在Testing里面供“勇者”和“探险者”来测试它们，并报告bug。

许多人都建议将所有软件包先经过testing而不是立刻就升级。这个主意被考虑过，但是开发者选择使用原来的方式，原因就是要“简单”，也是让一些被认为没有问题的软件包尽快的发布。这个问题已经决定了的，没有必要进行更多的讨论了。

软件仓库数量

曾有许多人建议过更改软件仓库的数量－－有的人认为应该多一些，有的认为应该少一些。现在的系统分为官方的软件仓库(current, release, extra, unstable, 和 testing)还有非官方的(主要是各种各样的 TURs 和staging)。

开发者已经决定了决不再增加软件仓库的数量，特别是官方的。用户们现在已经觉得有些混乱了。

也有一些关于减少软件仓库数量的讨论。官方的软件仓库已经不太可能减少了，因为每个仓库都有它们不同的作用。然而，“信任用户仓库(TUR)”将很可能会统一成一个单独的仓库，这是作为新软件包方案的一部分正在开发进程中。

也曾有关于在一个版本发布时更多的snapshot仓库的建议，特变是extra仓库的的snapshot。Arch被设计成一个滚动发布的统，也为当前仓库的软件包（包括current和extra）提供支持。release 仓库是在一个特定的时间对current仓库简单的snapshot，它们并比见得比当前的current更好或更稳定。

另外，Arch现在没有足够的人手来维护一个extra的snapshot。这将需要许多的后台支持和安全性BUG修正来满足许多应用。我们推荐用户们经常使用pacman -Syu来保持你的系统是最新的。

开发者们也正在讨论将来某个时候建立一个stable snapshot的可能性。这需要更多的开发者，因此这个想法在1.0发布之前可能无法完成。有个别的用户也建立有非官方的软件仓库。

其它格式的软件包

有人提议开发一个转换其它格式的软件包（比如RPM、apt、ebuild、slack）为pacman格式的工具。

我们鼓励创作和共享这样的工具，arch不太可能官方的去支持其它的软件包。原因有如下几条。

首先，用ABS和makepkg来创建Arch linux的软件包是十分简单的。由抓取的源码编译一个软件往往比使用其它发行版的软件包要做的工作少。

其次，Arch的软件包是为i686优化的，因此他们在这样的构架上运行是十分快的。大多数其它软件包是最多是为i586优化的，常常仅仅是i386。因此，软件包应该重新编译来进行优化。

第三，尽管pacman包是一个十分简单的格式，一些包格式还是不能很好的迁移到它上面。手动转换花的功夫会少一些。

第四，编译的软件包在Arch的滚动式发布系统下不会保持太久。比如，在Arch中Gcc和libc的升级相对其它任何发行版都要频繁。在老版本gcc和libc下编译的软件包可能经常与Arch冲突。

不同的软件包发布方式

几次见到有人建议Arch使用bzip2代替gzip来压缩软件包。这样可以节省少量的存储空间，使下载量更小，也节约一些带宽。

然而，下载量的减小只有拨号上网的用户会感觉出来，因为bzip2和gzip的区别不是那样的大。另外，bzip2比gzip解压的时间要多许多。在多数情况下，这比下载和安装一个软件包所用的时间还多。

另一种常出现的提议是使用二进差异的方式来处理软件包。这会使体积最大的软件包的下载需求减少。这样的缺点是它可能并不安全。原因之一是差异文件容易被黑掉，其二是差异文件不一定在每个环境下都能完美的工作。另外一个问题是和bzip2一样的，就是应用差异文件会消耗更多的时间。这也许就是二进差异在到目前为止都不是很被支持的最大原因，为实现它要进行大量的工作。

Dale已经就二进差异进行过一些实验，他发现由此节约的带宽数量根本值不上所要做的工作。他指出整个软件包的二进差异只比一个新的软件包小大约10％，甚至有些还大于新软件包。他说在每个文件使用差异比较将会改善结果，但是我们现在没有足够的开发者来完成这项工作。

事务处理和恢复

我们计划让pacman支持事务处理已经有一段时间了。这就是让pacman具有可以恢复旧版本软件包的能力。有时候一个软件包的升级会意想不到的把许多用户的系统弄糟，最快的（有时是唯一的）修复方法就是恢复到旧一些的版本。

尽管现在什么都还没实现，然而这个特性最终将会包含于pacman中。我们现在还无法详细介绍它，这也许是一个长期的项目。

你仍然可以使用CVS接口和makepkg来恢复软件包。看这个FAQ获得详细信息。

桌面环境和窗口管理器的菜单

开发者们正在为GUI程序开发一个基本菜单系统。当GUI程序被安装时这个系统会创建和更新默认菜单。

Arch提供的所有桌面环境和窗口管理器的菜单将会自动的更新，为管理者和用户减轻负担

Pacman 后台

Aurelien已经完成了一个pacman后台的设计计划。这个设计看起来相当的稳固。他打算10月中旬初步完成。他还需要实现一些想法（系统升级和升级记录）。到时，他会将alpha版本的代码和其他开发者共享。最终发布的如日期尚未确定。

用这种方法将pacman做成共享库可以让其它程序（比如GUI前端）可以很容易的调用pacman提供的函数。这要比直接调用pacman程序要更高效也更具扩展性。CLI（命令行接口) 前端当然还会长期保留。

软件包的 Changelog

有些人想要软件包的changelog。这会使Arch复杂化，与保持简单的原则是冲突的。

绝大多数软件包的改变仅仅是对软件包的升级，比如说，一个被打包的新程序的发布。几乎没有什么软件包的改变是写在PKGBUILD中的。如果你想知道这些改变，你可以去分析cvs的改变和网站上的注释。如果你想知道软件包中的新版本程序功能上有何改变，你可以去该程序的主页上去查询。

非自由软件包

一些用户要求提供一些Arch Linux的仓库中没有的非自由的软件包，另一些用户建议这些软件包应该被放在另外的仓库里。

开发者们不想增加一些不必要的仓库。他们也不想失去一些很有用的软件包。总体的立场是，在没有更好的自由版本软件可以替代的情况下，这些非自由的软件应该被包含进来。

有一个更为复杂的问题是，如何定义自由这个词？有些人认为只有GPL代码才可以被包含进来，另外一些人认为BSD式协议也应该被支持。目前存在着大量 的开源协议，以至于难以正确的包含或剔除某个软件包。

PKGBUILD现在提供了一个新字段叫做LICENSE。一旦多数的PKGBUILD支持这个新字段，它最终可以用来区别自由和非自由软件包。
如果用户们担心自己安装了非自由的软件包，他们应该在安装的软件包有依赖的情况下留意一下。