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. .. index:: license; variable 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. .. index:: d; variable 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.