模块化X移植指南

1.  背景

介绍

你可能会感到奇怪，曾经是漂亮、简单的一个xorg-x11包，变成了将近300个分开的包，这到底是为什么？这个解释肯定会让你觉得合理。=)这不是Gentoo背着X.org做的；恰恰是他们将所有的包分割开发布，而我们只是遵循他们的做法而已。

你可以研读模块化X迁移指南上的细节。

2.  依赖关系检查

我们想要尽可能精确的列举依赖关系，以使人们的系统上不必到处都是诸如XPrint之类用不到的东西。所以你想要直接依赖于需要的库和头文件，而不是任何类型的虚拟包。

而且，我们不能保证人们仅仅因为已经安装了元软件包，子软件包就一定已经被装上。消除掉这种不确定因素的将节省我们大量的时间。因为否则的话，我们就要花很多时间来把一些本不必存在的bug标记为无效。

如果我发现有任何包依赖于任一元软件包，我将会和该软件包的维护者争论到底。

第一步是安装模块化X，或者找个已经安装了它的人。这可以通过chroot实现──没有必要实际运行X，你只需要有它的文件来做依赖关系检查就够了。

$ wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
	http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb

第一个脚本，linking_libs.sh，检查编译日志以找到该软件包所有链接到的库，并打印那些库所属的包。如要获取编译日志，你可以在/etc/make.conf中设置PORT_LOGDIR，或者使用输出重定向。

$ ls /var/log/portage/*gdm* -l
-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
$ linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log

第二个脚本，included_headers.sh，扫描解压的源码包中以#include开头的行，并抓取包含在<>中的include文件。截至2005年9月9日，对于""风格的include它也能处理得和<>一样好。

第三个脚本，checkdeps.rb，使用来自pax-utils的scanelf来扫描一个软件包所安装的文件。它适用于二进制包或隐藏了编译输出的包。这是个Ruby脚本，因此它依赖于dev-lang/ruby以及app-misc/pax-utils。第四个脚本，pkgutil.rb，依赖于checkdeps.rb。

运行前两个脚本应该能给你提供一个很好的列表，包括RDEPEND（对于库）和DEPEND（对于头文件和库）。如果一个库出现在RDPEND列表而不在DEPEND列表中，这就可疑了；它可能是一个“错误依赖关系”（无任何原因而链接的库）。libXt是已知的具有如此特征的一个正确依赖关系；许多包通过检查libXt头文件来检查X。

included_headers.sh中的相对头文件搜索偶尔会找到错误的头文件，因为有一些头文件的名字是一样的，从而会返回一个不正确的包。通常这是非常明显的，比如Windows头文件会令它认为app-emulation/wine是一个依赖关系。

如果你指定-d选项，你偶尔会遇到某个库文件或头文件“Not found!”。这可能表示你在该包编译后卸载了它所需要的一个头文件，或者它是一个你尚未使用的可选头文件。如果是库文件的话，这可能表示你卸载了该库，或者它可能只是一个从未安装的内部构建的静态库。

花点时间来查查这些未被找到的头/库文件是否需要被添加到依赖关系列表是值得的，特别是对头文件，因为你不需要安装这些头文件就可以运行扫描。

在一些情况中，软件包要求某种形式的一个真实的X服务器。但是如果软件包在安装过程中事实上并不需要它，我鼓励你不要将它放到RDEPEND中。因为这样会破坏headless X配置，在这种配置里程序实际上运行在另一台机器上因而只需要本地库文件和头文件。

在portage树中已经有了一些X服务器，所以如果你确实需要X服务器，请把它们都包括进去。模块化X的服务器在xorg-server中；xdirectfb中有一个DirectFB服务器；kdrive提供了微型X服务器；当然还有旧的<xorg-x11-7。一定要指明xorg-x11的版本范围，以保证安装一个X服务器而不是元软件包。在不远的将来，我期待kdrive被移到xserver中。如果你确实需要一个X服务器，请联系X组的成员。如果很多软件包需要X服务器，我们可能为其创建一个虚拟包。

3.  依赖关系结构

要真正添加依赖关系──你会需要像这样的一个结构：

RDEPEND="|| ( ( x11-libs/libXfoo
			x11-libs/libXbar
			blah? ( x11-libs/libXblah )
			whatever else shows up in the library run
		)
		virtual/x11
	)

DEPEND="${RDEPEND}
	|| ( ( x11-proto/fooproto
			blah? ( x11-proto/blahproto )
			whatever else shows up in both script runs
		)
		virtual/x11
	)

这样的依赖关系结构可以默认使用新的模块化X配置，但同时如果人们还在用旧的整体式xorg-x11包的话，该依赖关系仍然可以被满足。我们正在彻底抛弃virtual/x11，以此来鼓励人们列举出精确的依赖关系。

对于整个树的首次修改，移植任务组只修复~arch用户能得到的最新ebuild，以及任何更新的ebuild（KEWORDS=-*或package.mask）。单独的软件包维护者可能选择这么做，并让不支持模块化X的ebuild逐步从树中淡出。但是他们最好把他们所有的ebuild都一次移植完。Repoman很快会因遇到任何强制依赖virtual/x11的ebuild而挂掉。

4.  处理USE标记

许多人不使用xinerama的USE标记。但是，如果当你运行inluded_headers.sh时，x11-proto/xineramaproto就会显示为一个依赖关系，然后添加它到xinerama标记的DEPEND中，并添加x11-libs/libXinerama到xinerama标记的RDEPEND中。

Caleb提出了一个好观点，那就是，对于拥有大量可选的X库依赖关系的包，如何处理它所有的USE标记？在许多情况下，总是强制开启或关闭标记是合乎情理的。而且，你可以通过把标记分组的方式让事情更简单一些。确保你是以标记的功能来命名它们，而不是它们使用的库或者包。

5.  将你的修正放到portage树中

如果你是开发人员，请检入它们。如果不是，请提交一个新bug，分配给包维护者（在metadata.xml中）。让它阻挡bug#112675，并附加一个修正依赖关系的补丁。

本文档的内容遵循知识共享-署名-相同方式共享许可协议