Manuale ia64 di Gentoo Linux: Installare Gentoo

I file di Portage

Direttive per la configurazione

Portage viene installato con una configurazione predefinita su /usr/share/portage/config/make.globals. L'intera configurazione di Portage viene gestita tramite variabili. Tutte le variabili prese in esame da Portage verranno descritte più avanti.

Siccome molte direttive di configurazione differiscono tra le varie architetture, Portage possiede dei file di configurazione predefiniti che fanno parte del profilo di sistema. Il link simbolico /etc/portage/make.profile punta a questo profilo; le configurazioni di Portage sono impostate nei file make.defaults del profilo e di tutti i profili padre. Forniremo maggiori spiegazioni sui profili e sulla cartella /etc/portage/make.profile più avanti.

Quando si modifica una variabile di configurazione, non si modifichi /usr/share/portage/config/make.globals o make.defaults. Si usi invece /etc/portage/make.conf che ha priorità sui file precedenti. Per ulteriori informazioni, leggere /usr/share/portage/config/make.conf.example. Come suggerisce il nome, questo è semplicemente un file di esempio - Portage non legge questo file.

È possibile definire una variabile di configurazione di Portage anche come variabile d'ambiente, ma non è raccomandabile.

Informazioni specifiche sul profilo

Abbiamo già incontrato la cartella /etc/portage/make.profile. Ebbene, questa non è esattamente una cartella ma un link simbolico ad un profilo, in via predefinita ad uno dentro /usr/portage/profiles/ sebbene sia possibile creare i propri profili altrove e puntare verso essi. Il profilo a cui punta questo link simbolico è il profilo a cui aderisce il sistema.

Un profilo contiene informazioni per Portage specifiche sull'architettura, per esempio un elenco di pacchetti facenti parte del sistema rispondenti a quel profilo, un elenco di pacchetti che non funzionano (o che sono mascherati) su quel profilo, ecc.

Configurazione specifica per l'utente

Quando serve modificare il comportamento di Portage riguardo l'installazione di software, è necessario modificare il giusto insieme di file dentro /etc/portage/. Si consiglia vivamente di utilizzare i file dentro /etc/portage/ e si sconsiglia fortemente di sovrascrivere tale comportamento attraverso le variabili d'ambiente!

All'interno di /etc/portage/ gli utenti possono creare i seguenti file:

• package.mask che elenca i pacchetti che Portage non dovrebbe mai provare ad installare
• package.unmask che elenca i pacchetti che Portage dovrebbe essere in grado di installare anche se gli sviluppatori di Gentoo scoraggiano molto gli utenti a farne uso
• package.accept_keywords che elenca i pacchetti che Portage dovrebbe essere in grado di installare anche se il pacchetto non è stato (ancora) considerato adatto per il sistema o per l'architettura
• package.use che elenca le opzioni USE (flag) da utilizzare per determinati pacchetti senza che l'intero sistema debba usare tali opzioni USE

Questi non devono essere necessariamente dei file; possono anche essere cartelle che contengono un file per pacchetto. Ulteriori informazioni sulla cartella /etc/portage/ ed un elenco completo dei file che si possono creare si trovano nella pagina manuale di Portage:

user $man portage

Cambiare le posizioni di file e cartelle di Portage

I file di configurazione menzionati in precedenza non possono essere memorizzati altrove - Portage cercherà quei file di configurazione sempre in quelle esatte posizioni. Tuttavia, Portage utilizza molte altre posizioni per vari scopi: cartelle per la compilazione, deposito del codice sorgente, posizione del repositorio di Gentoo, ...

Per tutti questi scopi ci sono posizioni predefinite ben note, ma possono essere modificate in base ai gusti personali tramite /etc/portage/make.conf. Il resto di questo capitolo spiega quali posizioni speciali utilizza Portage e come modificarne la posizione nel filesystem.

Comunque questo documento non è concepito per essere usato come riferimento. Per coprire il 100% degli argomenti, consultare le pagine manuale di Portage e make.conf:

user $man portage

user $man make.conf

Conservare i file

Repositorio di Gentoo

Il percorso predefinito del repositorio di Gentoo è /usr/portage. Esso è definito dal file predefinito repos.conf collocato su /usr/share/portage/config/repos.conf. Per modificare il valore predefinito, copiare questo file su /etc/portage/repos.conf/gentoo.conf e modificare l'impostazione di location. Quando si memorizza altrove il repositorio di Gentoo (modificando questa variabile), non si dimentichi di modificare coerentemente anche il collegamento simbolico /etc/portage/make.profile.

Dopo aver modificato l'impostazione di location su /etc/portage/repos.conf/gentoo.conf, si consiglia di modificare le seguenti variabili su /etc/portage/make.conf dato che non riceveranno avviso del cambiamento di location. Ciò dipende dal modo con cui Portage gestisce le variabili: PKGDIR, DISTDIR e RPMDIR.

Binari precompilati

Anche se Portage non usa i binari precompilati per impostazione predefinita, li supporta ampiamente. Quando si chiede a Portage di lavorare con i pacchetti precompilati, li cercherà in /usr/portage/pacchetti. Questa posizione è definita dalla variabile PKGDIR.

Codice sorgente

Il codice sorgente delle applicazioni è memorizzato in /usr/portage/distfiles per impostazione predefinita. Questa posizione è definita dalla variabile DISTDIR.

Il database di Portage

Portage memorizza lo stato del sistema (quali pacchetti risultano installati, quali file appartengono a quale pacchetto, ... ) su /var/db/pkg.

Attenzione
Non modificare questi file manualmente! Ciò potrebbe guastare le conoscenze di Portage sul sistema.

Cache di Portage

La cache di Portage (con i tempi di modifica, i virtuali, le informazioni sull'albero delle dipendenze, ... ) è memorizzata in /var/cache/edb. Questa posizione è effettivamente una cache (memoria provvisoria di supporto): gli utenti possono cancellarla se non stanno eseguendo applicazioni relazionate con Portage in quel momento.

Compilare il software

File di Portage temporanei

I file temporanei di Portage sono memorizzati in /var/tmp/ per impostazione predefinita. Ciò viene definito dalla variabile PORTAGE_TMPDIR.

Cartella di compilazione

Portage crea cartelle di compilazione specifiche per ogni pacchetto, le quali emergono dentro /var/tmp/portage/. Questa posizione è definita dalla variabile BUILD_PREFIX.

Posizione del filesystem live

In via predefinita, Portage installa tutti i file sul filesystem corrente (/), ma ciò può essere modificato impostando la variabile d'ambiente ROOT. Questo è utile quando si creano nuove immagini di pacchetti compilati.

Funzionalità di registro

Registro ebuild

Portage può creare file di registro (log) per ciascun ebuild, ma solo quando la variabile PORT_LOGDIR è impostata su una cartella scrivibile da Portage (tramite l'utente di Portage). In via predefinita questa variabile non è impostata. Se PORT_LOGDIR non è impostata, non ci saranno registri di compilazione (build) per il sistema di registro corrente, sebbene gli utenti possano ricevere alcuni registri dal nuovo supporto di elog.

Se PORT_LOGDIR non è definito e viene usato elog, i registri di compilazione e tutti gli altri registri salvati da elog saranno resi disponibili, come spiegato di seguito.

Portage offre un controllo preciso sulla registrazione tramite l'uso di elog:

• PORTAGE_ELOG_CLASSES: qui è dove gli utenti possono stabilire quali tipi di messaggi devono essere registrati. Può trattarsi di qualsiasi combinazione di info (informazioni), warn (avvisi), error (errori), log (registri) e qa (garanzie di qualità), separati da uno spazio.
  • info: registra i messaggi "einfo" stampati da un ebuild
  • warn: registra i messaggi "ewarn" stampati da un ebuild
  • error: registra i messaggi "eerror" stampati da un ebuild
  • log: registra i messaggi "elog" trovati in alcuni ebuild
  • qa: registra i messaggi "QA Notice" stampati da un ebuild

• PORTAGE_ELOG_SYSTEM: seleziona i moduli per elaborare i messaggi del registro. Se lasciato vuoto, la registrazione sarà disabilitata. È possibile utilizzare qualsiasi combinazione separata da uno spazio tra save (salvataggio), custom (personalizzato), syslog (registro di sistema), mail (posta), save_summary (sommario salvataggio) e mail_summary (sommario posta). Per poter utilizzare elog è necessario selezionare almeno un modulo.
  • save: salva un registro per pacchetto in $PORT_LOGDIR/elog, o in /var/log/portage/elog se $PORT_LOGDIR non è impostato.
  • custom: passa tutti i messaggi a un comando definito dall'utente su $PORTAGE_ELOG_COMMAND; ciò sarà discusso più tardi.
  • syslog: invia tutti i messaggi al registro di sistema installato.
  • mail: passa tutti i messaggi ad un server mail definito dall'utente su $PORTAGE_ELOG_MAILURI; ciò sarà discusso più tardi. Le funzionalità mail di elog richiedono >=portage-2.1.1.
  • save_summary: simile a save, ma unisce tutti i messaggi in $PORT_LOGDIR/elog/summary.log, o in /var/log/portage/elog/summary.log se $PORT_LOGDIR non è impostato.
  • mail_summary: simile a mail, ma invia tutti i messaggi in una sola mail quando emerge esce.

• PORTAGE_ELOG_COMMAND: viene utilizzato solo quando il modulo custom (personalizzato) è abilitato. Gli utenti possono specificare un comando per elaborare i messaggi di registro. Si noti che il comando può utilizzare due variabili: ${PACKAGE} che fornisce nome e versione del pacchetto, e ${LOGFILE} che fornisce il percorso assoluto del file di registro. Per esempio:

CODE Esempio di definizione di PORTAGE_ELOG_COMMAND

PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"

• PORTAGE_ELOG_MAILURI: contiene impostazioni per il modulo mail come indirizzo, utente, password, server mail, e numero della porta. L'impostazione predefinita è "root@localhost localhost". Il seguente esempio è per un server SMTP che richiede un'autenticazione basata su nome utente e password tramite una particolare porta (quella predefinita è la 25):

CODE Esempio di definizione di PORTAGE_ELOG_MAILURI

PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"

• PORTAGE_ELOG_MAILFROM: consente all'utente di impostare l'indirizzo "da" (from) delle e-mail di registro; il valore predefinito è "Portage" se non viene impostato.

• PORTAGE_ELOG_MAILSUBJECT: consente all'utente di creare una riga per l'oggetto per le e-mail di registro. Si noti che può utilizzare due variabili: ${PACKAGE} visualizzerà il nome e la versione del pacchetto, mentre ${HOST} il nome di dominio completo dell'host su cui Portage è in esecuzione. Per esempio:

CODE Esempio di definizione di PORTAGE_ELOG_MAILSUBJECT

PORTAGE_ELOG_MAILSUBJECT="pacchetto \${PACKAGE} compilato su \${HOST} con qualche messaggio"

Importante
Gli utenti che hanno utilizzato enotice con Portage-2.0.* devono rimuovere completamente enotice, in quanto non è compatibile con elog.

Configurazione di Portage

Come evidenziato in precedenza, Portage è configurabile attraverso molte variabili che dovrebbero essere definite in /etc/portage/make.conf o in una delle sotto cartelle di /etc/portage/. Si prega di fare riferimento a make.conf ed alle pagine manuale di portage per ulteriori e più complete informazioni:

user $man make.conf

user $man portage

Opzioni specifiche per la compilazione

Opzioni per configurare e compilare

Quando Portage compila le applicazioni, passa il contenuto delle seguenti variabili al compilatore e configura lo script:

CFLAGS e CXXFLAGS

Definiscono le opzioni desiderate per il compilatore di C e C++.

CHOST

Definisce le informazioni dell'host che compila per lo script di configurazione dell'applicazione

MAKEOPTS

Viene passato al comando make e solitamente definisce il numero di parallelismi usati durante la compilazione. Ulteriori informazioni sulle opzioni per make (crea) si trovano nella pagina manuale di make.

Anche la variabile USE viene usata durante la configurazione e le compilazioni, ma è già stata spiegata in dettaglio nei capitoli precedenti.

Opzioni incorporamento

Quando Portage incorpora (merge) una nuova versione di un titolo software, rimuoverà dal sistema i file obsoleti della versione precedente. Portage lascia all'utente un ritardo di 5 secondi prima di rimuovere la versione precedente. Questi 5 secondi sono definiti dalla variabile CLEAN_DELAY.

È possibile dire ad emerge di usare certe opzioni ogni volta che viene eseguito impostando EMERGE_DEFAULT_OPTS. Alcune opzioni utili potrebbero essere --ask (chiedi), --verbose (verboso), --tree (albero) e così via.

Protezione file di configurazione

Posizioni protette di Portage

Portage sovrascrive i file forniti dalle versioni più recenti di un software, a meno che i file non siano memorizzati su una posizione protetta. Queste posizioni protette sono definite dalla variabile CONFIG_PROTECT e generalmente sono posizioni per i file di configurazione. L'elenco delle cartelle è delimitato da uno spazio.

Un file che andrebbe scritto in una posizione protetta viene rinominato e l'utente viene avvisato della presenza di una versione più recente del (presumibile) file di configurazione.

Per conoscere l'impostazione di CONFIG_PROTECT corrente, servirsi dell'output di emerge --info:

user $emerge --info | grep 'CONFIG_PROTECT='

Ulteriori informazioni sulla protezione dei file di configurazione di Portage sono disponibili nella sezione CONFIGURATION FILES della pagina manuale di emerge:

user $man emerge

Escludere delle cartelle

Per 'togliere la protezione' ad alcune sotto cartelle dentro posizioni protette, gli utenti possono utilizzare la variabile CONFIG_PROTECT_MASK.

Opzioni download

Posizioni dei server

Quando le informazioni o i dati richiesti non sono disponibili sul sistema, Portage li recupererà da Internet. Le posizioni dei server per le varie informazioni e i dati sui canali sono definite dalle seguenti variabili:

GENTOO_MIRRORS

Definisce un elenco di posizioni dei server che contengono codice sorgente (distfiles).

PORTAGE_BINHOST

Definisce una posizione specifica del server contenente i pacchetti precompilati per il sistema.

Una terza impostazione riguarda la posizione del server rsync che gli utenti utilizzano per aggiornare il proprio repositorio locale di Gentoo. Ciò viene definito nel file /etc/portage/repos.conf (o un file interno a quella cartella se è impostato come cartella):

sync-type

Definisce il tipo di server e i valori predefiniti di rsync.

sync-uri

Definisce un server in particolare che Portage userà per recuperare il repositorio di Gentoo.

Le variabili GENTOO_MIRRORS, sync-type, e sync-uri possono essere impostate automaticamente attraverso l'applicazione mirrorselect. Ovviamente, app-portage/mirrorselect deve essere prima installata affinché si possa usare. Per maggiori informazioni, vedere la guida in linea di mirrorselect:

root #mirrorselect --help

Se l'ambiente richiede l'uso di un server proxy, allora possono essere dichiarate le variabili http_proxy, ftp_proxy, e RSYNC_PROXY.

Comandi per prelevare

Quando Portage necessita di prelevare codice sorgente, usa wget in via predefinita. Ciò può essere cambiato tramite la variabile FETCHCOMMAND.

Portage è in grado di ripartire da un parziale scaricamento di codice sorgente. Usa wget per impostazione predefinita, ma ciò può essere modificato tramite la variabile RESUMECOMMAND.

Assicurarsi che FETCHCOMMAND e RESUMECOMMAND immagazzinino il codice sorgente nella posizione corretta. Le variabili \${URI} e \${DISTDIR} possono essere usate dentro altre variabili rispettivamente per puntare alla posizione del codice sorgente o ai distfile.

È possibile anche definire gestori specifici per protocollo con FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, e così via.

Impostazioni rsync

Non è possibile modificare il comando rsync usato da Portage per aggiornare il repositorio di Gentoo, ma è possibile impostare alcune variabili relative al comando rsync:

PORTAGE_RSYNC_OPTS

Imposta un numero di variabili predefinite utilizzate durante la sincronizzazione, separate da uno spazio. Queste non dovrebbero essere cambiate a meno che non si sappia esattamente cosa si stia facendo. Notare che alcune opzioni assolutamente obbligatorie saranno sempre usate anche se PORTAGE_RSYNC_OPTS è vuota.

PORTAGE_RSYNC_EXTRA_OPTS

Usato per impostare opzioni aggiuntive durante la sincronizzazione. Ogni opzione va separata con uno spazio:

--timeout=<number>

Definisce il numero di secondi di inattività per una connessione rsync prima che rsync consideri la connessione scaduta. Il valore predefinito è 180 ma gli utenti con connessione dial-up (modem tramite linea telefonica) o gli individui con computer lenti potrebbero voler impostare questo valore a 300 o più.

--exclude-from=/etc/portage/rsync_excludes

Esso punta ad un file che elenca i pacchetti e/o le categorie che rsync dovrebbe ignorare durante il processo di aggiornamento. In questo caso, punta a /etc/portage/rsync_excludes.

--quiet

Riduce le risposte in output sullo schermo.

--verbose

Stampa un elenco dei file (filelist) completo.

--progress

Mostra un indicatore di avanzamento per ciascun file.

PORTAGE_RSYNC_RETRIES

Definisce quante volte rsync deve provare a connettersi al ripetitore (mirror) indicato dalla variabile SYNC prima di rinunciare con i tentativi. Il valore predefinito della variabile è 3.

Per ulteriori informazioni su queste opzioni ed altro, leggere la pagina manuale di rsync (man rsync).

Configurazione di Gentoo

Selezione del ramo

È possibile modificare il ramo (branch) predefinito con la variabile ACCEPT_KEYWORDS. Il valore predefinito è il ramo stabile dell'architettura. Maggiori informazioni sui rami di Gentoo sono disponibili nel prossimo capitolo.

Funzionalità di portage

È possibile attivare alcune funzionalità di portage tramite la variabile FEATURES. Le funzionalità di Portage sono state discusse nei capitoli precedenti.

Comportamento di Portage

Gestione delle risorse

Con la variabile PORTAGE_NICENESS (favorevolezza) gli utenti possono aumentare o ridurre il valore di nice (priorità favorevole) con cui portage viene eseguito. Il valore PORTAGE_NICENESS viene aggiunto al valore nice corrente.

Per ulteriori informazioni sui valori di nice (priorità favorevole), vedere la pagina manuale di nice:

user $man nice

Comportamento dell'output

La variabile NOCOLOR, il cui valore predefinito è false, definisce se Portage debba disabilitare l'uso di un output (risposte in uscita) colorato.

Usare un ramo

Stabile

La variabile ACCEPT_KEYWORDS definisce quale ramo del software usare per il sistema. Il valore predefinito è il ramo stabile previsto per il software dell'architettura del sistema, ad esempio ia64.

FILE /etc/portage/make.confUsing the stable branch

# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="ia64"

Si consiglia di aggrapparsi al ramo stabile. Tuttavia, se la stabilità non è così importante e/o l'amministratore vuole aiutare Gentoo inviando segnalazioni di errori (bug) su https://bugs.gentoo.org, allora si può usare il ramo di prova (testing).

Testing

Attenzione
Hic sunt dracones! Running software from the testing branch may incur stability issues, imperfect package handling (for instance wrong/missing dependencies), frequent ebuild revisions (resulting in a lot of compiling) or packages that are broken in another, often unexpected, manner. System administrators who are less comfortable with Gentoo or Linux in general should avoid the testing branch. As noted previously, the Handbook recommends staying with the stable, more thoroughly tested branch.

Per utilizzare un software più recente, gli utenti possono prendere in considerazione l'utilizzo del ramo testing (di prova). Affinché Portage usi il ramo testing, aggiungere una ~ (tilde) davanti all'architettura.

FILE /etc/portage/make.confUsare il ramo testing

ACCEPT_KEYWORDS="~ia64"

Per esempio, per selezionare il ramo testing per l'architettura ia64, modificare /etc/portage/make.conf ed impostare:

Il ramo di prova è esattamente quello che dice - Testing (di prova). Se un pacchetto è in fase di test, significa che gli sviluppatori sentono che è funzionale ma non è stato testato a fondo. Gli utenti che usano il ramo testing potrebbero essere i primi a scoprire un bug (errore) nel pacchetto, in tal caso dovrebbero presentare una segnalazione di bug per renderlo noto agli sviluppatori.

Quando si passa dal ramo stabile (stable) a quello di prova (testing), gli utenti noteranno che molti pacchetti saranno aggiornati. Si tenga presente che, dopo essersi spostati sul ramo di prova, potrebbe essere difficile ritornare al ramo stabile.

Mixare stabile con testing

package.accept_keywords

È possibile chiedere a Portage di abilitare il ramo testing per particolari pacchetti ma utilizzando il ramo stabile per il resto del sistema. Per fare ciò, aggiungere la categoria ed il nome del pacchetto in /etc/portage/package.accept_keywords. È anche possibile creare una cartella (con lo stesso nome) ed elencare il pacchetto nei file di quella cartella.

Per esempio, per usare il ramo testing per gnumeric:

FILE /etc/portage/package.accept_keywordsUsare il ramo testing solo per l'applicazione gnumeric

app-office/gnumeric

Particolari versioni testing

Per utilizzare una specifica versione software dal ramo testing evitando che Portage utilizzi il ramo testing per aggiornarla alle versioni successive, aggiungere la versione nella posizione package.accept_keywords. In tal caso usare l'operatore =. È anche possibile inserire un intervallo di versione usando gli operatori <=, <, >, o >=.

Ad ogni modo, se l'informazione sulla versione viene aggiunta, un operatore deve essere usato. Senza l'informazione sulla versione, un operatore non può essere usato.

Nell'esempio seguente chiediamo a Portage di consentire l'installazione di gnumeric-1.2.13 anche se si trova nel ramo testing:

FILE /etc/portage/package.accept_keywordsConsentire la selezione di una versione specifica

=app-office/gnumeric-1.2.13

Pacchetti mascherati

package.unmask

Importante
Gli sviluppatori di Gentoo non offrono supporto per l'uso di pacchetti smascherati (forzatamente mostrati). Si prega di prestare la dovuta cautela quando si usano. Le richieste di supporto relative a package.unmask e/o package.mask potrebbero non ricevere risposta.

Quando un pacchetto è stato mascherato (nascosto) dagli sviluppatori di Gentoo, nonostante il motivo menzionato nel file package.mask (situato in /usr/portage/profiles/ per impostazione predefinita) un utente può voler continuare ad usare questo pacchetto, in tal caso aggiungere la versione desiderata (solitamente questa sarà esattamente la stessa riga dal file package.mask nel profilo) al file /etc/portage/package.unmask (o in un file in quella cartella se si tratta di una cartella).

To do so, the system administrator would add the target package version (usually this will be the exact same line from the package.mask file in the profile) to the /etc/portage/package.unmask location.

Per esempio, se =net-mail/hotwayd-0.8 è nascosto (mask), allora può essere mostrato (unmask) aggiungendo la stessa identica linea nella posizione package.unmask:

FILE /etc/portage/package.unmaskMostrare (unmask) un particolare pacchetto/versione

=net-mail/hotwayd-0.8

Nota
Se una voce in /usr/portage/profiles/package.mask contiene un intervallo di versioni del pacchetto, allora è necessario mostrare (unmask) solo le versioni effettivamente necessarie. Si legga la sezione precedente per sapere come specificare le versioni.

package.mask

È anche possibile chiedere a Portage di non prendere in considerazione un determinato pacchetto o una versione specifica di un pacchetto. Per fare ciò, nascondere (mask) il pacchetto aggiungendo una linea appropriata nella posizione /etc/portage/package.mask (in quel file o in un file in questa cartella).

Ad esempio, per impedire a Portage di installare sorgenti del kernel più recenti di gentoo-sources-6.6.21, aggiungere la seguente riga nella posizione package.mask:

FILE /etc/portage/package.maskNascondere (mask) gentoo-sources con versione maggiore di 6.6.21

>sys-kernel/gentoo-sources-6.6.21

dispatch-conf

dispatch-conf è uno strumento che aiuta ad unire i file ._cfg0000_<name>. I file ._cfg0000_<name> sono generati da Portage quando vuole sovrascrivere un file in una cartella protetta tramite variabile CONFIG_PROTECT.

Con dispatch-conf, gli utenti sono in grado di unire gli aggiornamenti ai loro file configurazione mentre si tiene traccia di tutti i cambiamenti. dispatch-conf conserva le differenze tra i file configurazione servendosi di aggiustamenti (patch) o utilizzando il sistema di revisione RCS. Ciò significa che se qualcuno commette un errore durante l'aggiornamento di un file di configurazione, l'amministratore può ripristinare il file alla versione precedente in qualsiasi momento.

Quando si usa dispatch-conf, gli utenti possono chiedere di tenere i file configurazione così come sono, usare il nuovo file di configurazione, modificare quello attuale o fondere i cambiamenti in modo interattivo. dispatch-conf possiede anche alcune interessanti funzionalità aggiuntive:

• Fonde automaticamente gli aggiornamenti ai file configurazione che contengono solo aggiornamenti ai commenti.
• Fonde automaticamente i file configurazione che differiscono solo per la quantità di spazi bianchi.

Modificare prima /etc/dispatch-conf.conf e creare la cartella a cui fa riferimento la variabile archive-dir. Poi eseguire dispatch-conf:

root #dispatch-conf

Quando si esegue dispatch-conf, i file di configurazione modificati saranno esaminati uno alla volta. Premere u per aggiornare (sostituire) il file di configurazione corrente con quello nuovo e passare al file successivo. Premere z per zappare (eliminare) il nuovo file di configurazione e passare al file successivo. Il tasto n indicherà a dispatch-conf di saltare al file successivo. Ciò può essere fatto per tardare un'unione fino ad un momento futuro. Una volta che tutti i file di configurazione sono stati sistemati, dispatch-conf uscirà. In qualsiasi momento è possibile utilizzare q per uscire dall'applicazione.

Per ulteriori informazioni, consultare la pagina manuale di dispatch-conf. Si descrive come fondere in modo interattivo i file di configurazione attuali con quelli nuovi, modificare i nuovi file di configurazione, esaminare le differenze tra i file, ed altro.

user $man dispatch-conf

quickpkg

Con quickpkg gli utenti possono creare archivi di pacchetti già installati nel sistema. Questi archivi possono essere utilizzati come pacchetti precompilati. Eseguire quickpkg è semplice: basta aggiungere i nomi dei pacchetti da archiviare.

Per esempio, per archiviare curl, orage e procps:

root #quickpkg curl orage procps

I pacchetti precompilati saranno archiviati in $PKGDIR (/var/cache/binpkgs/ in via predefinita). Questi pacchetti sono collocati in $PKGDIR/CATEGORY.

Usare un sotto insieme del repositorio di Gentoo

Escludere pacchetti e categorie

È possibile aggiornare selettivamente certe categorie/pacchetti ed ignorare le altre categorie/pacchetti. Ciò può esser fatto facendo escludere a rsync tali categorie/pacchetti durante l'operazione emerge --sync.

Attenzione
In order for this method to work, manifest verification must be disabled. This will reduce the security of the repo. To disable the verification, either disable the rsync-verify USE flag on the sys-apps/portage package or set sync-rsync-verify-metamanifest=no (see man 5 portage) in the repos.conf entry of the Gentoo ebuild repository.

Definire nella seguente variabile il nome del file che contiene i modelli (pattern) di esclusione: PORTAGE_RSYNC_EXTRA_OPTS in /etc/portage/make.conf:

FILE /etc/portage/make.confDefinire il file delle esclusioni

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

FILE /etc/portage/rsync_excludesEscludere tutti i giochi

games-*/*

Si noti tuttavia che ciò può portare a problemi con le dipendenze dato che i nuovi pacchetti consentiti potrebbero dipendere da pacchetti nuovi ma esclusi.

Aggiungere ebuild non ufficiali

Definire un repositorio personalizzato

Manual creation

È possibile chiedere a Portage di usare ebuild non ufficialmente disponibili tramite il repositorio di Gentoo. Creare una nuova cartella (ad esempio /usr/local/portage) in cui archiviare gli ebuild di terze parti. Usare la stessa struttura di cartelle del repositorio di Gentoo ufficiale!

root #mkdir -p /usr/local/portage/{metadata,profiles}

root #chown -R portage:portage /usr/local/portage

Poi, scegliere un nome significativo per il repositorio. Il seguente esempio usa "localrepo" come nome:

root #echo 'localrepo' > /usr/local/portage/profiles/repo_name

Then define the EAPI used for the profiles within the repository:

root #echo '8' > /var/db/repos/localrepo/profiles/eapi

Indicare a Portage che il repositorio master è quello principale di Gentoo e che il repositorio non deve essere sincronizzato automaticamente (poiché non è supportato da un server rsync, o da un distributore (mirror) git o da altra fonte di repositori):

FILE /usr/local/portage/metadata/layout.conf

masters = gentoo
auto-sync = false

Infine, abilitare il repositorio sul sistema locale creando un file di configurazione del repositorio su /etc/portage/repos.conf ed informando Portage dove sarà possibile trovare il repositorio locale:

FILE /etc/portage/repos.conf/localrepo.conf

[localrepo]
location = /usr/local/portage

Optional: Creating a repo using eselect repository

Alternatively, a custom ebuild repository can be quickly created using the eselect repository module (from app-eselect/eselect-repository). In the following example, substitute localrepo with a name of choice:

root #eselect repository create localrepo

Adding localrepo to /etc/portage/repos.conf/eselect-repo.conf ...
Repository <ebuild_repository_name> created and added

A bare repository named "localrepo" will be made available at /var/db/repos/localrepo.

Lavorare con diverse sovrapposizioni

For those desiring to develop several ebuild repos, test packages before they hit the Gentoo repository, or who want to use unofficial ebuilds from various sources, the app-eselect/eselect-repository package also provides tooling to aid in keeping repositories up to date. See also eselect repository article.

Adding a repo using eselect repository

For instance, to enable the GURU repository:

root #eselect repository enable guru

Updating of repositories added with this methods will occur automatically on each sync:

root #emerge --sync

Software non gestito da Portage

Usare Portage con software autogestito

A volte gli utenti desiderano configurare, installare e gestire il software individualmente senza che Portage automatizzi il processo, anche se Portage può fornire quei titoli software. I casi noti sono sorgenti del kernel e driver Nvidia. È possibile configurare Portage affinché sappia che un determinato pacchetto viene installato manualmente (e quindi tener conto di questa informazione durante il calcolo delle dipendenze). Questo processo è chiamato iniezione (injecting) ed è supportato da Portage tramite il file /etc/portage/profile/package.provided.

Per esempio, per informare Portage che gentoo-sources-6.6.21 è stato installato manualmente, aggiungere la seguente riga a /etc/portage/profile/package.provided:

FILE /etc/portage/profile/package.providedSegnare gentoo-sources-6.6.21 come manualmente installato

sys-kernel/gentoo-sources-6.6.21

Nota
Questo è un file che usa versioni senza un operatore =.

Introduzione

Per la maggior parte degli utenti, le informazioni comunicate finora sono sufficienti per tutte le loro operazioni su Linux. Ma Portage può fare molto di più; molte delle sue funzionalità sono per utenti esperti o applicabili solo in casi specifici e marginali. Tuttavia, ciò non vorrebbe essere una scusa per non documentarli.

Naturalmente, insieme a tanta flessibilità si accompagna un enorme elenco di casi potenziali. Non è possibile documentarli tutti qui. Piuttosto, intendiamo concentrarci su alcuni problemi generici che possono essere adattati alle esigenze personali. Maggiori trucchi e consigli si possono trovare sul Wiki di Gentoo.

La maggior parte, se non tutte le funzionalità aggiuntive, possono essere facilmente individuate cercando tra le pagine manuale fornite da Portage:

user $man portage

user $man make.conf

Infine, tener presente che si tratta di funzionalità avanzate che, se non gestite correttamente, possono rendere molto difficile il debug e la risoluzione dei problemi. Assicurarsi di menzionarle quando ci si imbatte in un bug e si apre un bug report (rapporto errori).

Variabili d'ambiente per pacchetto

Usare /etc/portage/env

Per impostazione predefinita, le compilazioni (build) dei pacchetti useranno le variabili d'ambiente definite in /etc/portage/make.conf, come CFLAGS, MAKEOPTS ed altre. In alcuni casi, tuttavia, potrebbe essere utile fornire variabili diverse per specifici pacchetti. Per fare ciò, Portage supporta l'uso di /etc/portage/env e /etc/portage/package.env.

Il file /etc/portage/package.env contiene l'elenco dei pacchetti per i quali sono necessarie variabili d'ambiente diversificate ed un identificatore specifico che indichi a Portage quali modifiche apportare. Il nome dell'identificatore è in formato libero e Portage cercherà le variabili nel file /etc/portage/env/IDENTIFIER.

Esempio: Usare il debug per pacchetti specifici

Come esempio, abiliteremo il debug per il pacchetto media-video/mplayer.

Prima di tutto, impostare le variabili di debug in un file chiamato /etc/portage/env/debug-cflags. Il nome è scelto arbitrariamente, ma certamente riflette la ragione della modifica per rendere più chiara, in seguito, quale modifica è stata inserita.

root #mkdir /etc/portage/env

FILE /etc/portage/env/debug-cflagsVariabili specifiche per il debug

CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

Poi, etichettiamo il pacchetto media-video/mplayer per usare questo contenuto:

FILE /etc/portage/package.envUsare debug-cflags per il pacchetto mplayer

media-video/mplayer debug-cflags

Agganci nel processo di compilazione

Usare /etc/portage/bashrc ed i file affiliati

Quando Portage lavora con gli ebuild, utilizza un ambiente bash in cui chiama le varie funzioni di build (come src_prepare, src_configure, pkg_postinst, ecc.). Ma Portage permette agli utenti di configurare anche un ambiente bash specifico.

Il vantaggio dell'utilizzo di un ambiente bash specifico consiste nel permettere agli utenti di collegarsi al processo di emerge (compilazione) durante ogni fase eseguita. Ciò può essere fatto per ogni compilazione (tramite /etc/portage/bashrc) o usando ambienti specifici per pacchetto (tramite /etc/portage/env come discusso in precedenza).

Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name and post_phase_name. For example, Portage will call the post_pkg_postinst hook just after calling the pkg_postinst phase function.

Per agganciarsi (inserirsi) nel processo, l'ambiente bash può ascoltare le variabili EBUILD_PHASE, CATEGORY così come le variabili che sono sempre disponibili durante lo sviluppo di ebuild (come P, PF, ... ). In base ai valori di queste variabili, è possibile eseguire aggiuntivi passaggi o funzioni.

Esempio: Aggiornare il database dei file

In questo esempio, useremo /etc/portage/bashrc per chiamare alcune applicazioni database di file per garantire che i loro database siano aggiornati rispetto al sistema. Le applicazioni usate nell'esempio sono aide (uno strumento di rilevamento delle intrusioni) e updatedb (da usare con mlocate), ma sono da intendersi come esempi. Non si consideri ciò come una guida per AIDE!

Per usare /etc/portage/bashrc in questo caso, dobbiamo "agganciare" alle funzioni postrm (dopo la rimozione dei file) e postinst (dopo l'installazione dei file), perché è in quel momento che i file sul file system risultano modificati.

FILE /etc/portage/bashrcAggancio alle fasi postinst e postrm

if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
  echo ":: Chiamare aide --update per aggiornare il suo database"
  aide --update
  echo ":: Chiamare updatedb per aggiornare il suo database"
  updatedb
fi

post_pkg_postinst() { my_database_update; } post_pkg_postrm() { my_database_update; } }}

Eseguire attività dopo --sync

Usare la posizione /etc/portage/postsync.d

Fino ad ora abbiamo parlato dell'aggancio ai processi di ebuild. Tuttavia, Portage ha anche un'altra importante funzione: aggiornare il repositorio di Gentoo. Per eseguire attività dopo l'aggiornamento del repositorio di Gentoo, inserire uno script all'interno di /etc/portage/postsync.d ed assicurarsi che sia contrassegnato come eseguibile.

Esempio: Eseguire eix-update

Se eix-sync non è stato usato per aggiornare l'albero, allora è ancora possibile aggiornare il database eix dopo aver eseguito emerge --sync (o emerge-webrsync) inserendo un link simbolico verso /usr/bin/eix chiamato eix-update dentro /etc/portage/postsync.d.

root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update

Nota
Se viene scelto un nome diverso, allora deve essere uno script che chiama invece /usr/bin/eix-update. Il binario eix analizza come è stato chiamato per scoprire quale funzione deve eseguire. Se viene creato un collegamento simbolico che punta a eix quando ancora eix-update non è stato chiamato, non verrà eseguito correttamente.

Sovrascrivere le impostazioni del profilo

Usare /etc/portage/profile

In via predefinita, Gentoo utilizza le impostazioni contenute nel profilo a cui punta /etc/portage/make.profile (un collegamento simbolico alla corretta cartella del profilo). Questi profili definiscono sia impostazioni specifiche come anche ereditano impostazioni da altri profili (tramite il loro file genitore).

Usando /etc/portage/profile, gli utenti possono sovrascrivere le impostazioni del profilo come i pacchetti (cioè quali pacchetti si deve considerare siano parte del sistema), opzioni (flag) di uso forzato ed altro.

Esempio: aggiungere nfs-utils al sistema

Quando si utilizza un filesystem basato su NFS per filesystem piuttosto critici, potrebbe essere necessario marcare net-fs/nfs-utils come pacchetto di sistema, facendo in modo che Portage avvisi severamente gli amministratori se tentano di disinstallarlo.

Per soddisfare ciò, aggiungiamo il pacchetto a /etc/portage/profile/packages, preceduto da un *:

FILE /etc/portage/profile/packagesMarcare nfs-utils come pacchetto di sistema

*net-fs/nfs-utils

Applicare correzioni non standard

Patching source code using user patches in /etc/portage/patches/

User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.

Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.

Patches can be dropped into any of the following directories:

• /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
• /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
• /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/

Esempio: Applicare patch a Firefox

Il pacchetto www-client/firefox è uno dei tanti che chiama epatch_user già da dentro l'ebuild, quindi non c'è bisogno di sovrascrivere nulla di specifico.

Se per qualche motivo (per esempio uno sviluppatore ha fornito una correzione ed ha chiesto di verificare se è stato risolto l'errore segnalato) è necessario correggere Firefox, è sufficiente mettere la correzione (patch) in /etc/portage/patches/www-client/firefox (probabilmente è meglio usare il nome e la versione completi in modo che la patch non interferisca con le versioni successive) e ricompilare Firefox.