[ << ] [ < ] [ Home ] [ > ] [ >> ]

1. Guida agli Ebuild

• Il Portage tree
• Script ebuild
• Locazioni nel filesystem
• Gli script e le utilità di Portage
• Dipendenze dei pacchetti
• Testare e distribuire

1.a. Il Portage tree

Introduzione

Il portage tree si trova tipicamente in /usr/portage ed è organizzato in una struttura gerarchica consistente in directory categorizzate, seguite da directory specifiche per ogni pacchetto, per esempio è possibile trovare il file util-linux-2.11y.ebuild nella directory /usr/portage/sys-apps/util-linux. Possono esserci anche altre versioni di util-linux oltre che util-linux-2.11y.ebuild. Ciò è dovuto al fatto che tutti gli ebuild per un particolare pacchetto (indipendentemente dalla versione), condividono la stessa directory miacategoria/miopacchetto in /usr/portage, a meno che non si abbia installato un overlay di portage.

Effettuare il Check Out del Portage Tree dal CVS

Se il sistema CVS non è familiare, è consigliabile leggere la Guida al CVS di Gentoo Linux per maggiori informazioni.

Il Portage tree si trova nel modulo gentoo-x86 del Gentoo Linux tree. Per fare il check out del modulo (circa 350 megabyte) si deve prima configurare CVS tramite la guida precedente, poi fare il check out del modulo gentoo-x86.

Cosa (non) mettere nel Portage tree

Prima di scrivere un nuovo ebuild, controllare bugs.gentoo.org per verificare che non ci sia già un ebuild corrispondente ma non ancora inserito nel portage tree. Andare su bugs.gentoo.org, scegliere query e selezionare "Advanced Search" (Ricerca Avanzata); scegliere Gentoo Linux come prodotto e come componente ebuilds, nel campo ricerca mettere il nome dell'ebuild e come status scegliere NEW, ASSIGNED, REOPENED e RESOLVED (RESOLVED è importante), dopodiché inviare la query. Le persone pigre possono cliccare qui.

Generalmente, il Portage tree deve essere usato solo per contenere i file .ebuild insieme ad altri file relativamente piccoli, come patch o esempi di configurazione. Questi tipi di file devono essere posizionati nella directory /usr/portage/categoria/pacchetto/files per tenere pulita la directory categoria/pacchetto. Le eccezioni a questa regola sono per patch di grandi dimensioni (lo si raccomanda per patch più grandi di 20KB) che dovrebbero essere messe nei mirror Gentoo in modo che la gente non sprechi eccessivamente la larghezza di banda e lo spazio del disco fisso. Inoltre non si dovrebbero aggiungere al CVS del Portage Tree dei file binari (non ASCII). Se lo si deve fare in un altro ramo del CVS, per esempio, volendo aggiungere una piccola immagine PNG per qualsiasi ragione, assicurarsi di aggiungerla a CVS usando l'opzione -kb nel modo seguente:

# cvs add -kb miafoto.png

L'opzione -kb dice a CVS che miafoto.png è un file binario e deve essere trattato in maniera particolare. Per esempio, fondere le differenze di due versioni diverse di questo file, non deve essere reso possibile, per ovvie ragioni. Inoltre, riguardo alle fusioni di differenze, tutte le patch che si aggiungono a Portage devono necessariamente non essere compresse. Questo permette a CVS di fondere i cambiamenti e informare correttamente gli sviluppatori in caso di conflitti.

È importante ricordare che i pacchetti di cui si effettua il commit devono essere predisposti a funzionare in modo trasparente per gli utenti finali quando vengono marcati stabili. Assicurarsi di avere un buon insieme di impostazioni predefinite che soddisfino la maggior parte dei sistemi e degli utenti che utilizzeranno questo pacchetto. Se il pacchetto non dovesse funzionare, e non si è molto sicuri su come farlo funzionare, controllare altre distribuzioni che hanno già forgiato le loro versioni del pacchetto. È possibile controllare Mandriva o Debian o Fedora per qualche esempio.

Quando viene fatto il commit su CVS, tutti gli sviluppatori devono usare repoman commit al posto di cvs commit per inviare i propri ebuild. Prima di effettuare il commit, eseguire repoman full per essere sicuri di non aver dimenticato qualcosa.

Politica di Commit su CVS

• Eseguire sempre repoman scan prima del commit.
• Eseguire sempre repoman full prima del commit.
• Controllare sempre la correttezza di package.mask tramite il comando emerge --pretend miopacchetto prima del commit e verificare che non ci siano conflitti.
• Aggiornare sempre il ChangeLog prima del commit.
• Fate sempre il commit del file package.mask prima del pacchetto aggiornato, in caso ci siano conflitti durante il commit di package.mask.
• Fare sempre dei commit in modo atomico (ovvero un pezzo alla volta, non tutto insieme); se si esegue il commit di un pacchetto con una nuova licenza, o marcato "masked" (nascosto), prima eseguire il commit del package.mask rivisto e/o della licenza, poi l'ebuild, il ChangeLog, le patch e il file metadata.xml tutto in una volta, per evitare di rovinare l'installazione degli utenti.

La directory Files

Come indicato in precedenza, dentro ad ogni sottodirectory di ogni pacchetto c'è una directory files/. Qualunque patch, file di configurazione o altri file ausiliari richiesta dal proprio pacchetto vanno posizionati in questa directory; ogni file più grande di 20KB dovrebbe essere posizionato nei mirror per diminuire la quantità di file (non necessari) che gli utenti dovranno scaricare. Si può considerare di denominare le patch create autonomamente solo per far compilare correttamente il pacchetto con un nome specifico in base alla versione, per esempio miopacchetto-1.0-gentoo.diff o più semplicemente 1.0-gentoo.diff. Notare che l'estensione gentoo informa gli utenti che la patch è stata creata dagli sviluppatori Gentoo, piuttosto che recuperata da qualche mailing list o da altre fonti. Si ricorda nuovamente di non comprimere i file diff poiché CVS non gestisce in modo agevole i file binari.

Considerare l'aggiunta di un prefisso o suffisso come miopacchetto-1.0 al nome di ogni file dai posizionare in files/, per far sì che i file usati per ogni versione individuale di un ebuild siano distinguibili dagli altri, e che i cambiamenti fra le differenti revisioni siano visibili. Questa è generalmente una buona idea :). È possibile utilizzare suffissi diversi se si vuole dare maggior significato al nome della patch.

Se si hanno vari file da posizionare in files/, considerare la creazione di sottodirectory come ad esempio files/1.0/ e mettere i rispettivi file nella sottodirectory appropriata. Usando questo metodo, non c'è più bisogno di aggiungere le informazioni di versione ai nomi dei file. e spesso questa soluzione è più conveniente.

1.b. Script ebuild

Introduzione

Gli script ebuild sono la base dell'intero sistema di portage. Essi contengono tutte le informazioni necessarie allo scaricamento, estrazione, compilazione e all'installazione dei sorgenti, come anche ad eseguire qualsiasi installazione/rimozione opzionale o passaggio di configurazione pre/post installazione. Mentre la maggior parte di Portage è scritta in Python, gli ebuild sono scritti in bash, poiché usando bash è possibile richiamare i comandi come da linea di comando. Uno dei più importanti principi di progettazione su cui si basano gli script ebuild è l'avere a disposizione gli stessi comandi che si scriverebbero da riga di comando in un'installazione manuale del pacchetto. Per raggiungere questo scopo, usare la sintassi bash è un'ottima cosa.

Gli script ebuild vengono interpretati dai comandi ebuild ed emerge. Il comando ebuild è uno strumento di costruzione a basso livello. Può compilare ed installare un singolo ebuild. Controlla se le dipendenze sono soddisfatte, non tenta però di risolverle automaticamente. Dall'altra parte, emerge è un motore ad alto livello per ebuild ed ha l'abilità di auto-installare le dipendenze se necessarie, eseguire emerge simulati in modo che che l'utente possa vedere quali ebuild verranno installati, e molto altro. In generale, emerge rimpiazza totalmente ebuild tranne che in una area. Con ebuild è possibile eseguire in modo incrementale le varie parti dell'installazione di un pacchetto (scaricamento, estrazione, compilazione, installazione e "merging" - installazione vera e propria nel filesystem) una per volta. Per gli sviluppatori questo strumento ha un valore inestimabile, perché permette di isolare i problemi degli ebuild in una sua specifica porzione.

Dare il nome ai file ebuild

Il nome dei file ebuild consiste in quattro sezioni logiche:

pkg-ver{_suf{#}}{-r#}.ebuild

La prima sottosezione, pkg, è il nome del pacchetto, che dovrebbe contenere solo lettere minuscole, cifre 0-9 e un qualsiasi numero di questi caratteri : trattino singolo (-), "underscore" (_) o segno più (+). Ad esempio: util-linux, sysklogd e gtk+. Ci sono alcuni pacchetti in portage che non seguono queste regole, però i propri pacchetti dovrebbero farlo.

La seconda sottosezione, ver, è la versione del pacchetto, che dovrebbe essere normalmente la stessa dei sorgenti del tarball principale. La versione è solitamente formata da 2 o 3 (o più) numeri separati da punti, come 1.2 o 4.5.2, e può avere una lettera singola che segue l'ultima cifra, esempi: 1.4b o 2.6h. La versione del pacchetto viene collegata al suo nome con un trattino, ad esempio: foo-1.0, bar-2.4.6.

La terza sottosezione {_suf{#}}, è opzionale e può contenere uno tra questi suffissi predefiniti, ordinati dal meno recente al più recente:

Ognuno di questi suffissi può essere seguito da un numero intero positivo diverso da zero, per esempio linux-2.4.0_pre10. Assumendo che le parti della versione siano identiche, i suffissi sono ordinati come segue (il più basso significa il più vecchio): _alpha < _beta < _pre < _rc < (nessun suffisso) < _p.

Quando si comparano suffissi identici seguiti da numeri interi, quello con il numero intero più grande sarà considerato più recente. Esempio: foo-1.0_alpha4 è più recente di foo-1.0_alpha3.

La quarta sottosezione del nome di un pacchetto è il numero di revisione specifico di Gentoo Linux, ({-r#}). # è un numero intero positivo diverso da zero; esempio, package-4.5.3-r3.

Questo numero di revisione è indipendente dalla versione del sorgente tarball ed è usato per informare le persone che è disponibile una nuova e migliorata revisione Gentoo Linux di un pacchetto. Le versioni iniziali degli ebuild non devono avere nessun numero di revisione; per esempio, package-4.5.3 viene considerato da portage con un numero di revisione pari a zero. Questo significa che l'ordine è come segue: 1.0 (versione iniziale), 1.0-r1, 1.0-r2, ecc.

Se si introducono miglioramenti significativi ad un ebuild esistente, copiarlo in un nuovo file con il numero di revisione incrementato di 1. Ricordarsi sempre di menzionare i cambiamenti nel ChangeLog quando c'è una revisione e di inserire un messaggio sul CVS riguardante il proprio commit, non farlo è contro la politica del CVS.

Ovviamente c'è la quinta sezione del nome di un ebuild -- l'estensione .ebuild stessa.

Contenuti di un file ebuild

Questa sezione è una introduzione agli ebuild. Per l'elenco completo di ogni cosa possibile riguardante gli ebuild, c'è una pagina man che spiega il formato interno, le variabili, e le funzioni in uno script ebuild: man 5 ebuild.

Header

Quando si invia un ebuild, l'intestazione, o "header", dovrebbe essere esattamente uguale a quello in /usr/portage/header.txt. Ancora più importante, non modificarlo per nessun motivo e accertarsi che la riga $Header: $ sia intatta.

Le prime tre righe dovrebbe essere simile a queste:

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

Variabili

La prima parte di ogni ebuild è composta da un certo numero di variabili.Consultare la relativa sezione nel devmanual per le informazioni sulle diverse variabili disponibili.

Funzioni

In un file ebuild si possono definire varie funzioni per controllare il processo di compilazione e installazione del proprio pacchetto.

Funzioni di assistenza

Negli ebuild, inoltre, si possono usare le seguenti funzioni di assistenza .

Funzioni di assistenza fornite da eutils.eclass

Si possono usare nei propri ebuild le seguenti funzioni di assistenza fornite dall'eclass "eutils" . Assicurarsi che inherit eutils sia presente affinché queste funzioni vengano eseguite correttamente.

Funzioni di assistenza fornite da flag-o-matic.eclass

È possibile usare nei propri ebuild le seguenti funzioni di assistenza fornite dall'eclass "flag-o-matic". Assicurarsi che inherit flag-o-matic sia presente affinché queste funzioni vengano eseguite correttamente. Non si dovrebbero mai modificare direttamente le impostazioni del compilatore, usare invece flag-o-matic per effettuare qualsiasi azioni come filtrare le flag che causano problemi.

Funzioni di assistenza fornite da toolchain-funcs.eclass

Si possono usare nei propri ebuild le seguenti funzioni di assistenza fornite dall'eclass "toolchain-funcs". Assicurarsi che inherit toolchain-funcs sia presente affinché queste funzioni vengano eseguite correttamente. Non si dovrebbe mai specificare direttamente alcuna impostazione del compilatore o di binutils, usare invece toolchain-funcs per specificare compilatori e binutils.

Lo scopo di usare queste funzioni è quello di supportare il cross-compiling e il compilatore icc. Esse dovrebbero essere usate quando un pacchetto usa esplicitamente gcc, g++, ld, ranlib o qualunque di questi strumenti elencati di seguito. Generalmente i pacchetti che usano strumenti di autoconfigurazione rilevano automaticamente il cross compiling e non necessitano di queste funzioni.

Regole di scrittura di un file ebuild

Poiché i file ebuild sono semplicemente degli shell script, è possibile modificarli tramite gli usuali strumenti con cui si modificano gli script di shell. Si deve usare una certa indentazione, usare solo caratteri di tabulazione -- non spazi. Assicurarsi di configurare il proprio editor in modo da inserire 4 spazi per ogni tabulazione. Assicurarsi ogni volta di usare le parentesi attorno alle variabili d'ambiente; es. ${P} invece di $P.

Le linee lunghe vengono spezzate con ' \', così:

./configure \
--prefix=/usr || die "configure failed"

Per ulteriori dettagli, controllare skel.ebuild (di solito residente in /usr/portage).

Se si utilizza Vim per la modifica di ebuild/eclass, il file vimrc predefinito di Gentoo, /etc/vim/vimrc, assicura già che venga usata la corretta indentazione e le impostazioni associate ai tipi di file per gli ebuild e le eclass. Per ottenere risultati migliori, inclusa una speciale sintassi che evidenzia le parole chiave degli ebuild, installare app-vim/gentoo-syntax.

Su sistemi non Gentoo, si possono ottenere risultati simili con le seguenti righe nel proprio vimrc, o meglio ancora installando gli script gentoo-syntax, scaricabili dai mirror Gentoo.

au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh
au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab

Se si sta usando Emacs, si dovrebbe effettuare l'emerge di app-emacs/gentoo-syntax (per GNU EMacs) o app-xemacs/gentoo-syntax (per XEmacs). Questi pacchetti forniscono le modalità principali per l'indentazione automatica e l'evidenziazione della sintassi per gli ebuild e altri tipi di file specifici di Gentoo.

Se si sta usando nano, si è fortunati! Modificare /etc/nanorc e decommentare la sezione relativa agli ebuild.

Variabili USE

Lo scopo delle variabili USE è permettere di configurare Portage abilitando o disabilitando globalmente e automaticamente certe caratteristiche opzionali durante la compilazione. Per esempio, ipotizzando di essere dei fan di GNOME, potrebbe far piacere che per qualsiasi ebuild avente un'opzione di compilazione per il supporto a GNOME venga attivata questa caratteristica. In questo caso è necessario aggiungere gnome alla variabile USE in /etc/make.conf per far sì che Portage aggiunga in automatico il supporto opzionale GNOME ai pacchetti, se disponibile. Se invece non si vuole il supporto a GNOME, basta modificate /etc/make.conf e assicurarsi che gnome non sia indicato nella variabile USE. Gentoo Linux ha un numero grandissimo di opzioni USE, per permettere di configurare il sistema a proprio piacimento.

Nei propri ebuild, è possibile controllare se una variabile USE è impostata usando il comando use <variable>. Normalmente questo comando si usa in questo modo:

if use X ; then
  # comandi specifici per X ...
fi

Le variabili USE possono anche essere usate per impostare le dipendenze. Per esempio, si potrebbe voler installare un pacchetto solo se quella determinata variabile USE è impostata. Ciò viene fatto usando la sintassi flag? ( categoria/pacchetto) nella variabile DEPEND del proprio ebuild. In questo esempio categoria/pacchetto verrà richiesto solo se flag è presente in USE. È inoltre possibile specificare quale dipendenza usare se una flag USE è impostata, e quale dipendenza usare se non è impostata: flag? (categoria/pacchetto) e !flag? (altracategoria/altropacchetto). In questo caso, se flag non è impostata, altracategoria/altropacchetto viene usato al posto di categoria/pacchetto. Assicurarsi che i propri ebuild usino questa sintassi e non gli if di Bash. Le espressioni condizionali di Bash possono interferire con il caching delle dipendenze di Portage, ed il loro uso può rendere inutilizzabile l'ebuild.

Si dà un importante suggerimento su come usare USE. Il più delle volte un pacchetto avrà uno script ./configure utilizzato per eseguire i passaggi di configurazione. Generalmente, se il proprio ebuild usa ./configure, ogni caratteristica opzionale abilitabile durante la compilazione dovrà essere attivata o disattivata passando gli argomenti appropriati al comando ./configure. Questo è il modo migliore per farlo:

DEPEND="X? ( >=x11-base/xfree-4.3 )
mysql? ( >=dev-db/mysql-3.23.49 )
apache2? ( >=net-www/apache-2 )
!apache2? ( =net-www/apache-1* )"

src_compile() {
  econf \
    $(use_enable X x11) \
    $(use_enable mysql) \
    || die "Error: econf failed!"
  emake || die "Error: emake failed!"
}

Questo approccio dà dei buoni risultati. Non ci si deve preoccupare sull'impostazione predefinita per mysql o per X (abilitato/disabilitato),viene detto esplicitamente ad econf cosa fare in base alla variabile USE. Non occorre aggiungere che il codice è piuttosto chiaro in termini di leggibilità :).

A volte, gli ebuild hanno delle caratteristiche facoltative in conflitto fra di loro. Verificare questi conflitti e restituire un errore non è una soluzione fattibile. Piuttosto bisogna favorire una di queste caratteristiche rispetto alle altre. Riguardo a questo, consultare gli sviluppatori originali (cosa usano generalmente come scelta predefinita), o considerare quale opzione fornisce più funzionalità di uso comune, altrimenti tirare a sorte. Un esempio è l'ebuild di msmtp. Il pacchetto può usare sia SSL con GnuTLS, oppure SSL con OpenSSL, o nessun SSL. Siccome GnuTLS ha più funzionalità rispetto a OpenSSL, esso verrà favorito:

src_compile() {
    local myconf

    if use gnutls ; then
        myconf="${myconf} --enable-ssl --with-ssl=gnutls"
    elif use ssl ; then
        myconf="${myconf} --enable-ssl --with-ssl=openssl"
    else
        myconf="${myconf} --disable-ssl"
    fi

    econf \
        # Other stuff
        ${myconf} \
        || die "configure failed"

    emake || die "make failed"
}

Per vedere una tabella in continuo aggiornamento delle variabili USE, andare in questa pagina.

1.c. Locazioni nel filesystem

Introduzione a FHS

Gli standard del layout del filesystem usati in Gentoo Linux seguono scrupolosamente FHS, abbreviazione di Filesystem Hierarchy Standard (Standard della Gerarchia del Filesystem). Una descrizione semplificata dello standard viene data qui, per una descrizione specifica andare all'indirizzo: http://www.pathname.com/fhs/.

Come adeguare i pacchetti al filesystem

Abitualmente, se il pacchetto usa autoconf e automake, le destinazioni d'installazione predefinite sono quasi sempre corrette, salvo alcune eccezioni:

• Se si sta installando un programma in /bin, /sbin, /usr/bin o /usr/sbin, la sua pagina man deve essere installata in /usr/share/man. Ciò può essere fatto specificando ./configure --mandir=/usr/share/man all'intero dell'ebuild.
• I file GNU info, devono essere sempre installati in /usr/share/info, anche se sono file riguardanti X11, GNOME o programmi o strumenti specifici di KDE. Prendete nota: /usr/share/info è la sola locazione ufficiale per i file GNU info. Siccome gli script ./configure installano in modo predefinito i file info GNU in /usr/info, spesso è necessario chiamare ./configure con l'argomento --infodir=/usr/share/info.
• I file di documentazione sono installati in /usr/share/doc, in una sottodirectory che riflette il nome la versione e la revisione del particolare programma. Questo va applicato a tutti i programmi: GNOME, KDE, X11 o programmi per console. Comunque, alcuni programmi possono installare documentazione addizionale o file di supporto in una directory /usr/share per i scopi autonomi.
• I programmi specifici per X11 e le librerie devono essere sempre installati in /usr, e non direttamente in /usr/X11R6. Questo percorso è riservato all'X window system, versione 11 release 6. Questo è per interpretare più alla lettera le istruzioni di FHS, rispetto a come viene fatto da altre distribuzioni.
• I programmi GNOME e KDE, devono essere sempre installati dentro /usr.

In generale, bisogna far sì che gli ebuild installino i loro file in /usr. Alcuni programmi possono essere compilati e linkati con o senza le librerie GNOME, KDE e X11, cosa che può creare confusione. La soluzione proposta è installare tutto in /usr per evitare ambiguità e complessità inutili agli autori degli ebuild. La locazione nel filesystem di un programma non deve dipendere dalla presenza o dalla assenza di una variabile USE. Comunque, tutti gli ebuild nel portage tree quasi sempre effettueranno esclusivamente l'installazione nella gerarchia /usr.

1.d. Gli script e le utilità di Portage

Script pubblici

Questi sono gli script usati dall'amministratore di sistema per installare e rimuovere pacchetti, e mantenere il database degli stessi.

ebuild è il motore principale del sistema Portage; esegue le operazioni più importanti come l'estrazione, la compilazione, l'installazione, il merging e l'unmerging. Viene richiamato usando il comando: ebuild percorso/al/pacchetto.ebuild comando. I comandi disponibili sono:

emerge installa ricorsivamente il pacchetto e le sue dipendenze nel filesystem. Questo comando ha molte opzioni, eseguire emerge --help per un elenco.

env-update aggiorna i file di configurazione (includendo ma non limitato a /etc/ld.so.conf e /etc/profile.env) per includere le modifiche introdotte dai pacchetti installati.

Script e comandi privati

Questi sono script che si possono usare nell'ebuild per eseguire operazioni comuni.

Gli esperti possono consultare direttamente gli script in /usr/lib/portage/bin.

1.e. Dipendenze dei pacchetti

Perché le dipendenze sono importanti

Portage non è solamente un comodo script che offre un modo unificato per compilare qualsiasi progetto (programma, libreria) dai sorgenti. In aggiunta permette di scaricare ed installare automaticamente tutte le dipendenze necessaria, ovviamente specificandole nell'ebuild.

Negli ebuild ufficiali, tutte le dipendenze sono già specificate, quindi quando si esegue emerge net-www/mozilla/mozilla-1.0, Portage si assicurerà che tutte le librerie necessarie per compilare ed eseguire Mozilla siano correttamente installate prima che Mozilla stesso venga compilato.

Portage distingue le dipendenze build-time (in fase di compilazione) e run-time (in fase di esecuzione). (Avvertenza: Attualmente Portage installa tutte le dipendenze di compilazione e di esecuzione, lasciando poi tutto così com'è. In futuro sarà possibile ripulire la propria installazione in modo che rimangano installate solamente le dipendenze di esecuzione.).

Come specificare le dipendenze nei vostri files ebuild (a.k.a. DEPEND Atoms)

La variabile DEPEND all'interno dell'ebuild foo-x.y.z.ebuild dice a Portage quali sono i pacchetti necessari per compilare foo. La variabile RDEPEND specifica quali pacchetti sono necessari per eseguire foo. RDEPEND deve essere impostata esplicitamente anche se corrisponde esattamente a DEPEND poiché in futuro è pianificata la rimozione da Portage della sua valorizzazione predefinita a DEPEND.

DEPEND="virtual/opengl
    dev-libs/libxml2"
RDEPEND="${DEPEND}"

Ciò dice a Portage che per compilare foo-x.y.z sono necessari i pacchetti virtual/opengl (maggiori informazioni sui virtual a breve) e dev-libs/libxml2. Non dice niente su quale sia la versione richiesta di opengl o libxml2, ciò significa che "va bene qualsiasi cosa".

Il "va bene qualsiasi cosa" ovviamente è un po' inquietante, e generalmente non funzionerà. Però per le librerie che devono sempre essere al compatibili al 100% con i binari, attualmente funziona. Per le altre librerie, è possibile ovviamente specificare le dipendenze con la versione.

>=sys-apps/bar-1.2
=sys-apps/baz-1.0

>= e = fanno quello che ci si aspetta; va bene la versione 1.2 o superiore di sys-apps/bar (ciò significa che sys-apps/bar-2.0 può andare bene), mentre solamente la versione 1.0 di sys-apps/baz è accettata. Per maggiori informazioni sullo schema delle versioni dei pacchetti, vedere la precedente sezione Dare il nome ai file ebuild.

Questi sono altri modi di specificare le dipendenze delle versioni:

~sys-apps/qux-1.0
=sys-apps/foo-1.2*
!sys-libs/gdbm

~sys-apps/qux-1.0 selezionerà la revisione più nuova di qux-1.0

=sys-apps/foo-1.2* selezionerà il membro più nuovo della serie 1.2 e ignorerà le serie 1.3 e quelle precedenti/successive. Ciò significa che foo-1.2.3 e foo-1.2.0 sono valide, mentre foo-1.3.3, foo-1.3.0, e foo-1.1.0 non lo sono. Tenere presente che rientra nella corrispondenza anche foo-1.22.3 , che a volte potrebbe diventare un problema.

!sys-libs/gdbm impedirà l'installazione di questo pacchetto finché gdbm è già installato.

Note importanti

Ci sono molte cose difficili da capire con le variabili DEPEND e RDEPEND. Ecco alcuni punti importanti da seguire quando si scrivono le dipendenze.

• Includere sempre la CATEGORIA.
  Per esempio, usare >=x11-libs/gtk+-2 e non >=gtk+-2.
• Non mettere un asterisco (*) per le dipendenze di tipo >= .
  Per esempio, dovrebbe essere >=x11-libs/gtk+-2 invece di >=x11-libs/gtk+-2*.
• Mai mettere come dipendenza un meta-pacchetto.
  Non mettere gnome-base/gnome tra le dipendenze, ma inserire sempre le librerie specifiche come libgnome.
• Una dipendenza per riga.
  Non mettere dipendenze multiple su una stessa riga. Risultano difficili da leggere e da seguire.
• GTK: Usare sempre =x11-libs/gtk+-1.2* per applicazioni GTK+1.

Inoltre è importante assicurarsi di includere tutte le dipendenze necessarie per il proprio pacchetto:

• Guardare in configure.in o configure.ac
  Controllare qui le eventuali verifiche dei pacchetti. Le cose da guardare sono i controlli di pkg-config o le funzioni AM_* che controllano una specifica versione.
• Guardare i file .spec
  Una buona indicazione è guardare nei file .spec inclusi per le relative dipendenze. Tuttavia non farvi completamente affidamento, in quanto non è detto contengano l'elenco completo e definitivo delle dipendenze.
• Guardare il sito web dell'applicazione/libreria
  Controllare il sito web dell'applicazione per possibili dipendenze elencate come necessarie.
• Leggere gli eventuali file README e INSTALL del pacchetto
  Di solito contengono utili informazioni sulla compilazione e installazione dei pacchetti.
• Ricordarsi le dipendenze non binarie come pkg-config, programmi per la generazione dei documenti, ecc.
  Solitamente il processo di compilazione richiede dipendenze come intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc. Assicurarsi vengano chiaramente specificate.

Per tutti i dettagli più recenti sui DEPEND Atoms, vedere la sezione 5 della pagina man sugli ebuild: man 5 ebuild.

1.f. Testare e distribuire

ChangeLog

Ogni volta che si aggiorna (o si scrive un nuovo) ebuild bisogna sempre aggiornare il suo ChangeLog. Il file skel.ChangeLog contiene un semplice ChangeLog da usare come base.

Lo scopo del ChangeLog è documentare cosa è stato fatto, perché è stato fatto e da chi. Questo permette a sviluppatori e utenti di tracciare i cambiamenti in maniera semplice.

Il Changelog è fondamentalmente destinato agli utenti, per cui assicurarsi di mantenerne i contenuti concisi e puntuali, evitando di essere troppo prolissi nei dettagli tecnici.

Memorizzare localmente i propri ebuild

Per poter testare i propri ebuild e far sì che siano visibili da Portage, bisogna posizionarli in una directory conosciuta. Portage userà la variabile PORTDIR_OVERLAY, definibile in /etc/make.conf. Impostare questa variabile alla propria directory (per esempio /usr/local/portage).

In questa directory, si deve usare la stessa struttura (e le stesse categorie) di /usr/portage.

Usando PORTDIR_OVERLAY, i propri ebuild rimangono nel sistema, anche dopo un emerge --sync, e rimangono visibili da Portage.

Testare i pacchetti

Considerare le modalità di verifica con le quali accertarsi che il pacchetto funzioni. A volte gli sviluppatori includono una routine make test o make check che verificherà le funzionalità di base del pacchetto. Se ciò è vero, eseguire env FEATURES=test ebuild foo-x.y.z.ebuild test. Se il pacchetto risulta malfunzionante cercare di correggerlo in modo da farlo funzionare (e proporre la patch ai sviluppatori originali).

Se questo non è il caso considerare l'aggiunta di una routine src_test al proprio ebuild. Essa viene eseguita prima della routine src_install e può essere molto utile per testare il funzionamento del programma nelle varie architetture. Gli sviluppatori delle architetture apprezzeranno l'aggiunta di una routine di questo tipo, in quanto non sarà necessaria da parte loro la conoscenza della funzionalità del pacchetto.

Tenere a mente i requisiti generali di un ebuild in questo caso. La routine src_test non deve essere interattiva. Se il test routine dipende da altri pacchetti usare la flag USE test per specificare le dipendenze DEPEND per la compilazione. Inoltre le routine src_test non sono raccomandate per applicazioni grafiche X poiché l'utente che esegue portage spesso non può eseguirle con successo.

Strumenti utili per i test

Sono disponibili degli utili strumenti per aiutare nella scrittura e manutenzione degli ebuild.

[ << ] [ < ] [ Home ] [ > ] [ >> ]

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.