Ebuild file format¶
Coding style¶
- PG:
0101
- Source:
QA
- Reported:
partially via repoman and pkgcheck
While Gentoo leaves most of the coding style choices to developers, there are a few rules which we try to enforce. Those are:
Always indent using a single tab for indentation level. Do not attempt to align, as it will not work with different tab widths.
Whenever using named variables, use bracketed variable form, i.e.
${foo}rather than$foo.Use bash conditions
[[ ... ]]rather than POSIX-ish[ ... ]ortestbuiltin.
Rationale: the recommended constructs are less error-prone. Consistency avoids unnecessary changes when other developers edit the ebuild.
Code must be contained within ebuild and eclasses¶
- PG:
0102
- Source:
QA
- Reference:
- Reported:
no
The ebuild code must be fully contained within .ebuild and .eclass
files. It is forbidden to load additional ebuild code from other files
via source, eval or any other possible method.
This affects historical use of ‘eblits’ to include phase functions from external files. The eblits used by the few affected packages were converted into eclasses.
Rationale: moving ebuild code to non-standard locations is against the principle of least surprise. It makes the maintenance harder, confuses other developers and tools that do not explicitly account for that possibility, including linting tools.
HOMEPAGE must not contain variables¶
- PG:
0103
- Source:
QA
- Reported:
by pkgcheck, highlighted as error by gentoo-syntax
The HOMEPAGE variable in ebuild must specify all the URIs verbatim,
without referring to any variables. Variable references are allowed
when setting generic values in eclasses.
Rationale: since homepage URIs do not contain dynamic parts (such as package versions), there is little advantage to using variables there. On the other hand, variables render the URIs unusable without preprocessing, breaking URI support in terminals and editors, as well as reducing the usefulness of plain tools such as grep.
SRC_URI must not refer to HOMEPAGE¶
- PG:
0104
- Source:
QA
- Reported:
by pkgcheck
The SRC_URI variable in ebuild must not refer to ${HOMEPAGE}.
If both overlap, the common part must be repeated verbatim.
Rationale: HOMEPAGE permits multiple entries by design,
and developers are generally encouraged to add more helpful entries
(e.g. project pages on PyPI, GitHub…). Making individual URIs
incidentally depend on multi-valued variable having a single value
goes against the principle of least surprise. Furthermore, it makes
it hard to copy-paste part of the URI e.g. to investigate the directory
index.
KEYWORDS must be defined on a single line¶
- PG:
0105
- Source:
QA
- Reported:
no
The KEYWORDS variable must be defined at most once in an ebuild,
on a single line, with literal content (no variable references, line
wrapping, appending, etc.).
Rationale: it is common for arch teams to use the ekeyword tool
when working with large number of ebuilds. The tool has only limited
ability to process and modify ebuilds, and therefore developers must
make sure that it works correctly on their ebuilds.
LICENSE must not contain variables¶
- PG:
0106
- Source:
QA
- Reported:
no
The LICENSE variable in an ebuild must specify all the license names
verbatim, without referring to any variables. The only exception is
(implicit or explicit) use of LICENSE itself, i.e. appending is
allowed.
Rationale: since license names do not contain dynamic parts (such as package versions), using variables there has little advantage. On the other hand, variables reduce the usefulness of plain tools such as grep.
D must be used only in src_install and pkg_preinst¶
- PG:
0107
- Source:
QA
- Reported:
by pkgcheck
The D and ED variables must be used only in the src_install
and pkg_preinst phase functions. Exceptions to this policy can be
granted by the QA team.
Rationale: using D in other phases (e.g. src_configure) is
error-prone and may lead to the path being embedded in files of the
installed image. In addition, the directory pointed to by ${D}
does not exist in other phases.