Ci sono un certo numero di variabili speciali che devono essere configurate negli ebuild e molte altre che possono essere specificate opzionalmente. Ci sono anche alcune variabili predefinite che vengono usate in ogni parte dell'ebuild.
Le seguenti variabili vengono predefinite per l'utente e non dovrebbero essere sovrascritte.
| Variabile | Scopo |
|---|---|
| P | Nome e versione del pacchetto (revisione esclusa se presente), per esempio vim-6.3 |
| PN | Nome del pacchetto, per esempio vim |
| PV | Versione del pacchetto (revisione esclusa se presente), per esempio 6.3 |
| PR | Revisione del pacchetto o r0 se non è presente |
| PVR | Versione e revisione del pacchetto, per esempio 6.3-r0, 6.3-r1 |
| PF | Nome del pacchetto, versione e revisione, per esempio vim-6.3-r1 |
| A | Tutti i file sorgente per il pacchetti (esclusi quelli che non sono disponibili a causa di un flag USE) |
| CATEGORY | La categoria del pacchetto, per esempio app-editors |
| FILESDIR | Percorso della directory files/ dell'ebuild, usata comunemente per piccole patch e file. Valore: "${PORTDIR}/${CATEGORY}/${PN}/files" WORKDIR Percorso della directory di compilazione dell'ebuild. Valore: "${PORTAGE_TMPDIR}/portage/${PF}/work" |
| T | Percorso di una directory temporanea che può essere usata dall'ebuild. Valore: "${PORTAGE_TMPDIR}/portage/${PF}/temp" |
| D | Percorso della directory di installazione temporanea. Valore: "${PORTAGE_TMPDIR}/portage/${PF}/image" |
| ROOT | Percorso della directory principale. Quando non si usa ${D}, appendere sempre ${ROOT} al percorso. |
Le seguenti variabili devono essere definite in ogni ebuild.
| Variabile | Scopo |
|---|---|
| DESCRIPTION | Una piccola descrizione (meno di 80 caratteri) dello scopo del pacchetto |
| SRC_URI | Una lista di sorgenti URI per il pacchetto. Può contenere parti condizionali USE. |
| HOMEPAGE | La homepage del pacchetto |
| KEYWORDS | Vedere KEYWORDS. |
| SLOT | Lo SLOT per il pacchetto. Vedere SLOT. |
| LICENSE | La licenza del pacchetto, corrisponde esattamente ad un file in licenses/. |
| IUSE | Una lista di tutti gli USE flag usati nell'ebuild |
L'uso delle seguenti variabili è opzionale:
| Variabile | Scopo |
|---|---|
| S | Percorso della directory temporanea di lavoro, usata da src_compile e src_install. Default: "${WORKDIR}/${P}". |
| DEPEND | Una lista di pacchetti necessari per la compilazione. |
| RDEPEND | Una lista di pacchetti necessari per l'esecuzione. |
| PDEPEND | Una lista di pacchetti che devono essere installati dopo che il pacchetto è stato installato. Da usare solo se non è possibile impostare RDEPEND. |
| RESTRICT | Una lista delimitata da spazi per imporre delle limitazione del portage. Valori validi sono nostrip, nomirror, nouserpriv e fetch. |
| PROVIDE | Qualsiasi virtual fornito da questo pacchetto, per esempio "virtual/editor virtual/emacs". |
Quando non è necessario alcuno slot, usare SLOT="0". Non usare SLOT="" che disabiliterà lo slotting per questo pacchetto.
ll solo costrutto valido riguardante un * in KEYWORDS è un -*. Non usare KEYWORDS="*" o KEYWORDS="~*".
Vedere Keywording per sapere come gestire questa variabile.
E' permesso l'uso di sorgenti dei file condizionali basati su USE usando la sintassi flag? ( ). Questo è utile per codice o per pacchetti binari specifici per architettura. Il download di binari per sparc su ppc sarebbe uno spreco di banda.
Un esempio:
SRC_URI="http://example.com/files/${P}-core.tar.bz2
x86? ( http://example.com/files/${P}/${P}-sse-asm.tar.bz2 )
ppc? ( http://example.com/files/${P}/${P}-vmx-asm.tar.bz2 )
sparc? ( http://example.com/files/${P}/${P}-vis-asm.tar.bz2 )
doc? ( http://example.com/files/${P}/${P}-docs.tar.bz2 )"
Creando un digest può essere necessario avere tutti i componenti SRC_URI scaricati. Se si ha una variabile FEATURES="cvs" impostata, portage dovrebbe essere in grado di farlo correttamente benché si possa finire per scaricare più del necessario.
Se viene usata una variabile USE_EXPAND per controllare se certi componenti opzionali sono installati, la cosa corretta da fare se la variabile non è impostata è generalmente installare tutti i componenti disponibili.
Un esempio:
SRC_URI="http://example.com/files/${P}-core.tar.bz2
examplecards_foo? ( http://example.com/files/${P}-foo.tar.bz2 )
examplecards_bar? ( http://example.com/files/${P}-bar.tar.bz2 )
examplecards_baz? ( http://example.com/files/${P}-baz.tar.bz2 )
!examplecards_foo? ( !examplecards_bar? ( !examplecards_baz? (
http://example.com/files/${P}-foo.tar.bz2
http://example.com/files/${P}-bar.tar.bz2
http://example.com/files/${P}-baz.tar.bz2 ) ) )"
Notare che la variabile IUSE è cumulativa, per questo non è necessario specificare flag USE usati solo nelle eclass ereditate all'interno della IUSE dell'ebuild.
Flag USE per architettura (sparc, mips, x86-fbsd, etc.) non dovrebbero essere elencati così come flag auto-extend (linguas_en, etc.).
E' possibile specificare LICENSE multiple e voci che si applicano solo su un particolare flag USE impostato. Il formato è lo stesso di DEPEND.
Spesso il formato della versione dei tarball non segue le convenzioni usate da Gentoo. Differenze riguardanti l'uso dei caratteri di sottolineatura e trattini sono particolarmente comuni. Per esempio, quello che Gentoo chiama foo-1.2.3b potrebbe avere un tarball chiamato foo-1.2-3b.tar.bz2. Piuttosto che codificare i numeri di versione è preferibile usare una variabile MY_PV. Il modo più semplice per farlo è usare l'eclass versionator:
inherit versionator MY_PV=$(replace_version_separator 2 '-')
Questo codice ha il vantaggio che funzionerà anche se il tarball avesse un formato come foo-1.3-4.5.tar.bz2.
E' possibile usare anche i metodi di sostituzione della bash per ottenere lo stesso effetto (questo è il metodo utilizzato da internamente versionator), ma è complicato, passibile di errori e difficile da leggere.
Alcuni ebuild usano chiamate a sed, awk e / o cut, ma questo non dovrebbe più essere fatto per ogni nuovo codice e dovrebbe essere sostituito sia da versionator che dai metodi di bash substitution dove possibile.
L'eclass versionator può anche essere usato per estrarre particolari componenti da una stringa di versione. Ecco un breve sommario delle funzioni.
| Funzione | Scopo |
|---|---|
| get_all_version_components | Suddivide una stringa di versione nei suoi componenti. |
| get_version_components | Ottiene i componenti importanti della versione esclusi '.', '-' e '_'. |
| get_major_version | Ottiene la major version. |
| get_version_component_range | Estrae un range di sottoparti da una stringa di versione. |
| get_after_major_version | Ottiene tutta la parte dopo la major version. |
| replace_version_separator | Sostituisce un particolare separatore di verione. |
| replace_all_version_separators | Sostituisce tutti i separatori della versione. |
| delete_version_separator | Cancella un separatore dalla versione. |
| delete_all_version_separators | Cancella tutti i separatori dalla versione. |