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: no

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.