Variabili

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.

Variabili predefinite in sola lettura

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.

Variabili richieste

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

Variabili opzionali

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".

SLOT

Quando non è necessario alcuno slot, usare SLOT="0". Non usare SLOT="" che disabiliterà lo slotting per questo pacchetto.

KEYWORDS

ll solo costrutto valido riguardante un * in KEYWORDS è un -*. Non usare KEYWORDS="*" o KEYWORDS="~*".

Vedere Keywording per sapere come gestire questa variabile.

SRC_URI

Sorgenti condizionali

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 ) ) )"

IUSE

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.).

LICENSE

E' possibile specificare LICENSE multiple e voci che si applicano solo su un particolare flag USE impostato. Il formato è lo stesso di DEPEND.

Questione inerente la formattazione della versione

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.