[ << ] [ < ] [ 手册主页 ] [ > ] [ >> ]

3. 常见的ebuild错误

• 常见的Ebuild编写错误
• 常见的Ebuild提交错误
• 评论和建议

3.a. 常见的Ebuild编写错误

介绍

       这里有一个我从用户提交的ebuild里能看到的常见错误。请确保你提交的ebuild不要再犯这些错误。在提交任何ebuild之前，首先必须阅读Gentoo开发方针和Gentoo Ebuild手册。还有，看看里面的一些ebuilds（比如至少一两个），确认你知道ebuild编写的风格。

       还有，阅读一些使用eclass的ebuild和阅读Eclass手册帮助理解它们是很有用的。最后，在提交你的ebuild之前仔细的阅读发布Ebuild指南。

遗漏/错误/不全的文件头

       提交你的ebuild时，注意文件头必须和/usr/portage/skel.ebuild里的完全一样。特别重要的是，不要修改任何东西，确保$Header: $行是完整的。

       前面三行必须看起来和下面一样：

# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

       除非你在提交一个新加补丁或者改变版本号的ebuild，否则你不应该修改$Header: $行。但是无论如何，这一行必须在。当我们将检查ebuild，放入cvs时，将会修改文件头，带上正确的版本号和日期信息。因此，你没有必要手动修改它。

遗漏IUSE

       目前为止最常遗漏的变量IUSE。你必须（根据Gentoo手册）包含这个变量，即使没有USE参数可用也如此。如果不支持任何USE参数，就只需要加上下面的：

IUSE=""

重新定义的P, PV, PN, PF

       你永远都不应该重新定义这些变量。使用的时候一直要使用MY_P、MY_PN、MY_PV、P0等。可以查看其他的ebuild如何做的，以获得更多信息。大部分的ebuild都使用bash的“参数扩展（Parameter Expansion）”。请查看bash的手册页面以理解“参数扩展”的工作原理。

       另外，如果你发现有重新定义它的软件包，不用复制它，并提交一个这个ebuild的臭虫报告。

在SRC_URI和S里包含版本号

       你应该不要试图吧版本号包含在SRC_URI和S里。使用时一直要使用${PV}或者${P}。这会使维护这个ebuild更加容易。如果在一个源码包里版本号不是固定的，那么就使用MY_P。dev-python/pyopenal的一个例子取得名为PyOpenAl的源码包，因此我们就这样定义它：

MY_P=${P/pyopenal/PyOpenAL}
SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
S=${WORKDIR}/${MY_P}

DEPEND有语法错误

       用户提交的DEPEND和RDEPEND一栏中有很多不同的错误。这里有一个给你编写依赖性时需要遵守的一些要点。

• 必须有CATEGORY.
  比如说，使用>=x11-libs/gtk+-2而不是>=gtk+-2。
• 不要在>=依赖性上使用星号（*）
  比如何所，应该使用>=x11-libs/gtk+-2而不是>=x11-libs/gtk+-2*。
• 仅限于GTK。对于GTK+1的程序要一直使用 =x11-libs/gtk+-1.2* 。
• 不要依赖于一个半发行的软件包。
  因此不要依赖于gnome-base/gnome，而必须是特定的库如libgnome。
• 每行一个依赖性。
  不要在一行放入太多的依赖性。否则很难阅读，也难以记住。

DEPEND不全

       这是另一个很常见的错误。ebuild提交者提交了一个只是“刚能工作”而不去检查依赖性是否正确。这里有一些寻找正确依赖性的技巧。

• 阅读configure.in和configure.ac
  在这里查看软件包。我们要找的就可以用pkg-config检查或者用AM_*函数检查特定的版本。
• 看看自带的.spec文件
  依赖性的一个好的寻找方法是查看自带的.spec文件，以获得相关依赖性。但是，不要相信它们是绝对完整的依赖性列表。
• 查看程序／库的网站
  查看该应用程序的网站，以获得它们建议需要的可能的依赖性。
• 阅读软件包的README和INSTALL
  它们通常也包含了编译和安装软件包的有用信息。
• 记住非二进制的依赖性，如pkg-config，文档创建工具等
  通常情况下，编译的过程需要如intltool、libtool、pkg-config、doxygen、scrollkeeper、gtk-doc等依赖性。确保你已经清楚的陈述了这些。

LICENSE错误

       另一个用户常犯的错误是提交ebuild时提供了一个错误的版权。比如说，GPL不是一个正确的版权信息。你必须指定为GPL-1或者GPL-2。同样对LGPL也如此。确认你在LICENSE栏使用的版权信息是/usr/portage/licenses里已有的。给个小提示，可以查看源码包里的COPYING获得版权信息。如果一个软件包并没有指定是使用GPL-1或者GPL-2，很可能它是使用GPL-2。

       如果你提交的软件包的版权信息是很独特，并在/usr/portage/licenses里没有的，那么你必须以一个不同的文件提交这个新的版权信息。

KEYWORDS里未测试的ARCH

       除非这个ebuild在一个ARCH已经测试过，否则请不要添加其他的ARCH到KEYWORDS里。还有所有新的ebuild都应该标上~86或者其他它应该使用的架构上。确认你在改变版本号时，稳定的KEYWORDS都在前面标上~。 ~.

遗漏SLOT

       确认你已经在ebuild里设置了SLOT变量。如果你不准备使用它，也不要去掉它。填入：

SLOT="0"

DESCRIPTION和HOMEPAGE错误

       请检查一下是否变量HOMEPAGE是准确的，是否在用户想了解更多此软件包时能引导用户到正确的页面。一篇优秀的概要将会用一句话将这个软件包的主要函数描述出来。

完全错误的用空格代替TABS

       按格式编写好几行的ebuild并不有趣，因为提交者并没有按照准则使用TABS而不是许多空格。因此请使用tab键！

留下很多空格

       我常常觉得这是一种犯罪。记住在你的ebuild上运行一下repoman，这样它会告诉你最后一行带的多余的空格或者是空的行。

添加多余的S=${WORKDIR}/${P}

       如果S=${WORKDIR}/${P}，那么你不要把他添加到你的ebuild上。这个我们已经提过，你只需在不是${WORKDIR}/${P}的时候添加上它。

遗漏文档

       如果你的软件包有文档，确认你使用dodoc并把它装在/usr/share/doc/${PF}。记住运行dodoc/doins时检查错误。

3.b. 常见的Ebuild提交错误

介绍

       请按照Gentoo文档页面里的发布Ebuild手册正确的提交ebuild。

将ebuild打包

       请千万不要将附上的ebuild打包。附上补丁时也要单独出来，这样我们可以比较容易的检查它们。

内部的ebuild

       不要剪切和粘贴一个ebuild里的内容到bugzilla评论栏。

没有是哪个软件包的描述

       请让我们明白这个软件包是什么，如果有的话，填上这个应用程序的主页的地址。

软件包更新但没有改变描述

       如果你提交一个软件更新，那么要确认解释了你对这个ebuild做的改变。比如说，如果一个软件包引进了新的特性／选项并且你要使用一个USE参数，将它们列表于你的bug中。不要让我们去找这些东西。

       软件更新时提交一个diff文件比一个整的ebuild文件要明智很多。最好的创建diff的方法可能是：

$ diff -u some-package-0.1.0.ebuild some-package-0.2.0.ebuild > ~/some-package-0.2.0.diff

为改变版本号提交没变的ebuild

       如果你要为Portage里的一个软件包提交一个新的版本，确定已有的ebuild仍然可以工作，并且新的ebuild里所做的改变是不兼容的（如添加文档）。如果这和前一版本没有必须的改变，那就不要附上这个ebuild了。只需要在bug报告中说出来，你将这个ebuild已经复制过去，并检验这个软件包仍然可以正常的工作和安装。

3.c. 评论和建议

       有关的评论、校正和建议请联系Alastair Tse。

[ << ] [ < ] [ 手册主页 ] [ > ] [ >> ]