1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
Ebuild file format
==================
.. index::
single: bash; conditions
single: bash; variable reference
single: indentation
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 ``[ ... ]``
or ``test`` builtin.
*Rationale*: the recommended constructs are less error-prone.
Consistency avoids unnecessary changes when other developers edit
the ebuild.
.. index:: eblit
Code must be contained within ebuild and eclasses
-------------------------------------------------
:PG: 0102
:Source: QA
:Reference: https://bugs.gentoo.org/612630
: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.
.. index:: homepage; variable
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.
.. index::
pair: src uri; homepage
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.
.. index:: keywords; one line
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.
|
GitWeb