Gentoo Linux ppc64 Handbook: Working with Gentoo

Benvenuto su Portage

Portage è una delle più notevoli innovazioni di Gentoo per la gestione del software. Grazie alla sua grande flessibilità e all'enorme quantità di caratteristiche, è considerato spesso il miglior strumento di gestione del software disponibile per Linux.

Portage è scritto completamente in Python e Bash e di conseguenza è completamente visibile agli utenti in quanto entrambi sono linguaggi di script.

La maggior parte degli utenti lavorerà con Portage tramite lo strumento emerge. Questo capitolo non è pensato per duplicare le informazioni disponibili tramite la pagina man di emerge. Per un resoconto completo delle opzioni di emerge, per favore si consulti la pagina man:

user $man emerge

Il repositorio di Gentoo

Ebuild

Quando la documentazione di Gentoo parla di pacchetti, intende i titoli dei software che sono disponibili per gli utenti di Gentoo attraverso il repositorio di Gentoo (repository). Questo repositorio è una raccolta di ebuild, ovvero file che contengono tutte le informazioni di cui Portage necessita per mantenere il software (installazioni, ricerche, interrogazioni, ecc.). Queste ebuild risiedono normalmente nel percorso /usr/portage.

Ogni qual volta qualcuno chiede a Portage di effettuare un'azione riguardante i titoli del software, userà come base le ebuild nel sistema. Di conseguenza, è importante aggiornare regolarmente le ebuild, così che Portage venga a conoscenza del nuovo software, degli aggiornamenti di sicurezza, ecc.

Aggiornare il repositorio di Gentoo

Il repositorio di Gentoo è solitamente aggiornato tramite rsync, una veloce utilità di trasferimento file incrementale. L'aggiornamento è piuttosto semplice in quanto il comando emerge fornisce un front-end (interfaccia utente) per rsync:

root #emerge --sync

Talvolta vengono applicate restrizioni tramite firewall tali da impedire a rsync di contattare i mirror. In questo caso, si aggiorni il repositorio di Gentoo tramite le istantanee (snapshot) di Gentoo generate quotidianamente. Lo strumento emerge-webrsync preleva ed installa automaticamente l'istantanea più recente sul sistema:

root #emerge-webrsync

Manutenzione del software

Ricerca del software

Ci sono vari modi per cercare del software nel repositorio di Gentoo. Un modo è tramite emerge stesso. In via predefinita, emerge --search restituisce i nomi dei pacchetti il cui titolo corrisponde (completamente o parzialmente) al termine di ricerca inserito.

Per esempio, per cercare tutti i pacchetti che contengono "pdf" nel loro nome:

user $emerge --search pdf

Per cercare anche nelle descrizioni, usare l'opzione --searchdesc (o -S):

user $emerge --searchdesc pdf

Si noti che l'output restituisce molte informazioni. I campi sono chiaramente etichettati perciò non approfondiremo il loro significato:

CODE Esempio di output per il comando di ricerca

*  net-print/cups-pdf
      Latest version available: 2.6.1
      Latest version installed: [ Not Installed ]
      Size of files: 33 KiB
      Homepage:      http://www.cups-pdf.de/
      Description:   Provides a virtual printer for CUPS to produce PDF files
      License:       GPL-2

Installazione del software

Quando un titolo di un software viene trovato, allora l'installazione dista giusto ad un comando di emerge. Per esempio, per installare gnumeric:

root #emerge --ask app-office/gnumeric

Poiché molte applicazioni dipendono l'una dall'altra, qualunque tentativo di installare un certo software potrà anche comportare l'installazione di numerose dipendenze. Non serve preoccuparsene, Portage gestisce bene le dipendenze. Per scoprire cosa installerebbe Portage, aggiungere l'opzione --pretend. Per esempio:

root #emerge --pretend gnumeric

To do the same, but interactively choose whether or not to proceed with the installation, add the --ask flag:

root #emerge --ask gnumeric

Durante l'installazione di un pacchetto, Portage scaricherà il codice sorgente necessario da Internet (se necessario) e lo conserverà su /usr/portage/distfiles/. Dopodiché spacchetterà, compilerà ed installerà il pacchetto. Per dire a Portage di scaricare solamente i sorgenti senza installarli, aggiungere l'opzione --fetchonly al comando emerge:

root #emerge --fetchonly gnumeric

Trovare la documentazione dei pacchetti installati

Molti pacchetti possiedono una loro documentazione. Talvolta, l'opzione USE doc determina se la documentazione di un pacchetto debba essere installata oppure no. Per vedere se l'opzione USE doc viene usata da un certo pacchetto, usare emerge -vp category/package:

root #emerge -vp media-libs/alsa-lib

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

Il miglior modo per abilitare l'opzione USE doc per un certo pacchetto è tramite /etc/portage/package.use, così che venga installata solo la documentazione per i pacchetti voluti. Per ulteriori informazioni, consultare la sezione Opzioni USE del manuale.

Una volta installato il pacchetto, la sua documentazione si trova generalmente in una sotto cartella presente su /usr/share/doc/ e nominata con il nome del pacchetto:

user $ls -l /usr/share/doc/alsa-lib-1.1.3

total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

Un modo più sicuro per elencare i file della documentazione installati è usare l'opzione --filter di equery. equery viene usato per interrogare il database di Portage ed è parte del pacchetto app-portage/gentoolkit:

user $equery files --filter=doc alsa-lib

 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

L'opzione --filter può essere usata con altre regole per vedere i percorsi di installazione di molti altri tipi di file. Ulteriori funzionalità sono documentate nella pagina man di equery: man 1 equery.

Rimozione del software

Per rimuovere il software da un sistema, usare emerge --unmerge. Ciò dirà a Portage di rimuovere dal sistema tutti i file installati da quel pacchetto. Un'eccezione a ciò sono tutti i file di configurazione di quell'applicazione "se" sono stati modificati dall'utente. Lasciare i file di configurazione permette agli utenti di continuare a lavorare con il pacchetto senza bisogno di riconfigurarlo se viene reinstallato successivamente.

root #emerge --unmerge gnumeric

Quando un pacchetto viene rimosso dal sistema, le dipendenze di quel pacchetto che sono state installate automaticamente quando era stati installato vengono lasciate intatte nel sistema. Per far sì che Portage individui tutte le dipendenze che ora possono essere rimosse, usare la funzionalità --depclean di emerge, che verrà discussa in seguito.

Aggiornare il sistema

Per mantenere il sistema in perfetta forma (per non contare l'installazione degli aggiornamenti di sicurezza più recenti) è necessario aggiornare regolarmente il sistema. Poiché Portage controlla solo le ebuild nel repositorio di Gentoo, la prima cosa da fare è aggiornare proprio questo. Quando il repositorio di Gentoo risulta aggiornato, può essere aggiornato il sistema usando emerge --update @world. Nell'esempio successivo, viene usata anche l'opzione --ask, che specifica a Portage di mostrare la lista dei pacchetti da aggiornare e di chiedere conferma:

Portage passerà a cercare versioni più recenti delle applicazioni installate. Tuttavia, verificherà solo le versioni delle applicazioni che sono state esplicitamente installate (le applicazioni elencate in /var/lib/portage/world) - non controllerà a fondo tutte le loro dipendenze. Per aggiornare anche le dipendenze di quei pacchetti, aggiungere l'opzione --deep:

root #emerge --update --deep @world

Se le impostazioni USE del sistema sono state alterate, è raccomandato aggiungere anche --newuse. Così, Portage verificherà se il cambiamento richiede l'installazione di nuovi pacchetti o la ricompilazione di alcuni esistenti:

root #emerge --update --deep --with-bdeps=y --newuse @world

Metapacchetti

Alcuni pacchetti nel repositorio di Gentoo non hanno un effettivo contenuto, ma sono usati per installare una raccolta di pacchetti. Per esempio, il pacchetto kde-apps/kde-meta installerà nel sistema un ambiente KDE completo scaricando vari pacchetti relativi a KDE come dipendenze.

Per rimuovere un pacchetto del genere dal sistema, eseguire emerge --unmerge sul pacchetto non avrà molto effetto in quanto le dipendenze rimarranno nel sistema.

Portage possiede anche la capacità di rimuovere le dipendenze rimaste orfane, ma poiché la disponibilità del software presenta dipendenze dinamiche, per prima cosa è importante aggiornare completamente il sistema, inclusi i nuovi cambiamenti applicati al variare delle opzioni USE. Fatto questo, si esegua emerge --depclean per rimuovere le dipendenze rimaste orfane. Fatto anche questo, potrebbe essere necessario ricompilare le applicazioni che erano dinamicamente collegate ai pacchetti ora rimossi, ma non più richiesti, benché recentemente sia stato aggiunto a Portage del supporto per questo.

Tutto ciò viene gestito con i seguenti tre comandi:

root #emerge --update --deep --newuse @world

root #emerge --depclean

root #revdep-rebuild

Licenze

A partire dalla versione 2.1.7 di Portage, è possibile accettare o rifiutare l'installazione del software in base alla sua licenza. Tutti i pacchetti nell'albero contengono una voce LICENSE nelle loro ebuild. Eseguire emerge --search package/category mostrerà la licenza del pacchetto.

Importante
{{{1}}}

Normalmente, Portage dà il consenso a tutte le licenze, ad eccezione degli Accordi di Licenza con l'Utente Finale (End User License Agreements - EULAs) che richiedono la lettura e la firma di un accordo di accettazione.

La variabile che controlla le licenze permesse viene chiamata ACCEPT_LICENSE, che può essere impostata nel file /etc/portage/make.conf. Nell'esempio seguente, viene mostrato il suo valore predefinito:

FILE /etc/portage/make.confL'impostazione predefinita di ACCEPT_LICENSE

ACCEPT_LICENSE="* -@EULA"

Con questa configurazione, i pacchetti che richiedono l'interazione dell'utente durante l'installazione per accettare la propria licenza EULA non saranno installabili. Invece, i pacchetti senza una licenza EULA saranno installabili.

È possibile impostare ACCEPT_LICENSE globalmente su /etc/portage/make.conf, oppure specificarla per ciascun pacchetto tramite file /etc/portage/package.license.

Per esempio, per dare il consenso alla licenza google-chrome per il pacchetto www-client/google-chrome, aggiungere quanto mostrato di seguito nel file /etc/portage/package.license:

FILE /etc/portage/package.licenseAccettare la licenza google-chrome per il pacchetto google-chrome

www-client/google-chrome google-chrome

Questo permette l'installazione del pacchetto www-client/google-chrome, ma proibisce l'installazione del pacchetto www-plugins/chrome-binary-plugins, anche se ha la stessa licenza.

Or to allow the often-needed sys-kernel/linux-firmware:

FILE /etc/portage/package.licenseAccepting the licenses for the linux-firmware package

# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Importante
Le licenze sono conservate nella cartella /usr/portage/licenses/, e i gruppi di licenze sono mantenuti nel file /usr/portage/profiles/license_groups. Il primo valore di ciascuna linea in lettere MAIUSCOLE è il nome del gruppo di licenze, ed ogni valore successivo è una licenza individuale.

I gruppi di licenze definiti nella variabile ACCEPT_LICENSE hanno un prefisso che è il simbolo @. Un'impostazione comunemente richiesta è permettere solamente l'installazione di software e documentazione liberi. Per ottenere ciò, rimuovere tutte le licenze attualmente accettate (usando -*) e poi permettere solo le licenze nel gruppo FREE come mostrato di seguito:

FILE /etc/portage/make.confAccettare solamente software e documentazione liberi

ACCEPT_LICENSE="-* @FREE"

Note that this setting will also accept non-free software and documentation.

Quando Portage si lamenta

Terminologia

Come affermato in precedenza, Portage è estremamente potente e supporta molte caratteristiche di cui sono privi altri strumenti di gestione del software. Per comprenderle, spiegheremo alcuni aspetti di Portage senza entrare troppo nei dettagli.

Con Portage, possono coesistere diverse versioni di un singolo pacchetto su un sistema. Mentre altre distribuzioni tendono a chiamare i loro pacchetti con il numero di versione (come freetype e freetype2), Portage usa una tecnologia chiamata SLOT (fessura). Un'ebuild dichiara un certo SLOT per la sua versione. Possono coesistere ebuild con diversi SLOT nello stesso sistema. Per esempio, il pacchetto freetype ha ebuild con SLOT="1" e SLOT="2".

Ci sono anche pacchetti che forniscono la stessa funzionalità ma che sono implementati in modo diverso. Per esempio, metalogd, sysklogd, e syslog-ng sono tutti logger (registratori di eventi) di sistema. Le applicazioni che si basano sulla disponibilità di un "logger di sistema" non possono dipendere, per esempio, da metalogd, in quando gli altri logger di sistema sono anch'essi una valida scelta. Portage permette di usare logger virtuali: ogni logger di sistema viene elencato come una dipendenza "esclusiva" del servizio di logging (registrazione eventi) nel pacchetto virtuale logger dalla categoria virtuale, così che le applicazioni possano dipendere dal pacchetto virtual/logger. Una volta installato, il pacchetto rappresenterà il primo pacchetto di logging menzionato in esso, a meno che non sia stato già installato un pacchetto di logging (in tal caso quello virtuale risulta soddisfatto).

Il software nel repositorio di Gentoo può risiedere in rami diversi (branch). Normalmente il sistema accetta solo pacchetti che Gentoo reputa stabili. La maggior parte del software nuovo, una volta caricato, viene aggiunto al ramo di prova (testing), per far capire che serve testarlo più a lungo prima di poterlo segnalare come stabile. Benché le ebuild per quei software siano nel repositorio di Gentoo, Portage non le aggiornerà finché non saranno poste nel ramo stabile (stable).

Alcuni software sono disponibili solo per poche architetture. Magari il software non funziona su altre architetture, oppure ha bisogno di più prove, oppure lo sviluppatore che ha aggiunto il software al repositorio di Gentoo non è in grado di verificare se il pacchetto funziona su architetture diverse.

Ogni installazione di Gentoo aderisce anche ad un determinato profilo che contiene, tra le altre informazioni, l'elenco dei pacchetti necessari affinché un sistema funzioni normalmente.

Pacchetti bloccati

CODE Avvertimento di Portage riguardo i pacchetti bloccati (con --pretend)

[blocks B     ] mail-mta/ssmtp (sta bloccando mail-mta/postfix-2.2.2-r1)

• Error: The above package list contains packages which cannot be

* installed at the same time on the same system.

(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by

   x11-wm/i3

Le ebuild contengono campi specifici che informano Portage sulle loro dipendenze. Ci sono due dipendenze possibili: dipendenze di costruzione, dichiarate nella variabile DEPEND e dipendenze per l'esecuzione, dichiarate similmente in RDEPEND. Quando una di queste dipendenze segnala esplicitamente un pacchetto effettivo o virtuale come non compatibile, innesca un blocco.

Sebbene le versioni recenti di Portage sono abbastanza intelligenti da eludere i blocchi minori senza l'intervento dell'utente, occasionalmente tali blocchi devono essere risolti manualmente.

Per risolvere un blocco, gli utenti possono scegliere di non installare il pacchetto o di disinstallare prima il pacchetto in conflitto. Nell'esempio dato, si può optare di non installare postfix o di rimuovere prima ssmtp.

Talvolta ci sono anche pacchetti bloccanti con parti specifiche non divisibili, come per esempio <media-video/mplayer-1.0_rc1-r2. In questo caso, l'aggiornamento dello stesso ad una versione più recente potrebbe rimuovere il blocco.

È anche possibile che due pacchetti ancora da installare si blocchino fra loro. In questo raro caso, si tenti di scoprire perché debbano essere installati entrambi. Nella maggior parte dei casi, è sufficiente procedere con uno solo dei pacchetti. Se così non fosse, si segnali cortesemente un errore nel sistema di tracciamento degli errori di Gentoo.

Pacchetti mascherati

CODE Avvertimento di Portage riguardo i pacchetti mascherati

!!! tutti gli ebuilds che potrebbero soddisfare "bootsplash" sono stati mascherati.

CODE Avvertimento di Portage riguardo i pacchetti mascherati - motivo

!!! possibili candidati sono:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

Quando si tenta di installare un paccheto non disponibile per il sistema, avviene un errore di mascheramento. Gli utenti dovrebbero cercare di installare un'applicazione diversa che sia disponibile per il sistema oppure attendere finché il pacchetto non sarà marcato come disponibile. C'è sempre una ragione se un pacchetto viene mascherato:

Motivo del mascheramento	Descrizione
~arch keyword	L'applicazione non è stata testata sufficientemente per poter essere messa nel ramo stabile. Attendere qualche giorno o settimana e riprovare.
-arch keyword or -* keyword	L'applicazione non funziona sulla propria architettura. Se si ritiene che il pacchetto funzioni, presentare istanza dell'errore sul sito web Bugzilla.
missing keyword	L'applicazione non è ancora stata testata sulla propria architettura. Chiedere alla squadra di esportazione dell'architettura di testare il pacchetto oppure lo si testi per loro e si riporti il risultato sul sito web di Bugzilla.
package.mask	Il pacchetto si è rivelato corrotto, instabile o anche peggio ed è stato deliberatamente marcato come da non usare.
profile	Il pacchetto si è rivelato inadatto per il profilo attuale. L'applicazione potrebbe danneggiare il sistema se viene installato oppure semplicemente non è compatibile con il profilo attualmente in uso.
license	La licenza del pacchetto non è compatibile con il valore di ACCEPT_LICENSE. Accetta la sua licenza o imposta il gruppo di licenze corretto configurandolo su /etc/portage/make.conf o su /etc/portage/package.license

Modifiche necessarie delle opzioni USE

CODE Avviso di Portage riguardo la necessità di modificare delle opzioni USE

Le seguenti modifiche a USE sono necessarie per procedere:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

Il messaggio di errore potrebbe anche essere mostrato come segue, se --autounmask non è impostato:

CODE Errore di Portage riguardo la necessità di cambiare l'opzione USE

emerge: non ci sono ebuild costruite con le opzioni USE che soddisfino "app-text/feelings[test]".
!!! È necessario uno dei seguenti pacchetti per completare la propria richiesta:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Tale avvertimento od errore avviene quando si richiede di installare un pacchetto che non solo dipende da un altro pacchetto, ma anche richiede che quel pacchetto sia compilato con una particolare opzione USE (o un insieme di opzioni USE). Nell'esempio mostrato, il pacchetto app-text/feelings deve essere compilato con USE="test", ma questa opzione USE non è impostata nel sistema.

Per risolvere ciò, si aggiunga l'opzione USE richiesta alle opzioni USE globali in /etc/portage/make.conf, oppure impostarla per lo specifico pacchetto in /etc/portage/package.use.

Dipendenze mancanti

CODE Avvertimento di Portage riguardo le dipendenze mancanti

emerge: non ci sono ebuild per soddisfare ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problema con l'ebuild sys-devel/gcc-3.4.2-r2
!!! È possibile che sia un problema DEPEND/*DEPEND.

L'applicazione da installare dipende da un altro pacchetto che non è disponibile per il sistema. Si controlli su Bugzilla se il problema è noto e se così non fosse, lo si segnali. A meno che il sistema non sia configurato per mescolare i rami, questo problema non dovrebbe verificarsi e di conseguenza è un errore.

Nome ebuild ambiguo

CODE Avvertimento di Portage riguardo nomi ebuild ambigui

[ Risultati per il termine di ricerca : listen ]
[ Applicazioni trovate : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Ultima versione disponibile: 1.1.15
      Ultima versione installata: [ Not Installed ]
      Dimensione file: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Descrizione:   Raw listen for TinyOS
      Licenza:       BSD
  
*  media-sound/listen [ Masked ]
      Ultima versione disponibile: 0.6.3
      Ultima versione installata: [ Not Installed ]
      Dimensione file: 859 kB
      Homepage:      http://www.listen-project.org
      Descrizione:   A Music player and management for GNOME
      Licenza:       GPL-2
  
!!! Il nome breve dell'ebuild "listen" è amibiguo. Specificare
!!! uno dei precedenti nomi ebuild completi al suo posto.

L'applicazione selezionata per essere installata ha un nome che corrisponde a più di un pacchetto. Si fornisca anche il nome della categoria per risolvere questo problema. Portage informerà l'utente sulle possibili corrispondenze tra cui scegliere.

Dipendenze circolari

CODE Avvertimento di Portage riguardo le dipendenze circolari

!!! Errore: dipendenze circolari: 
  
ebuild / net-print/cups-1.1.15-r2 dipende dall'ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 dipende dall'ebuild / net-print/cups-1.1.15-r2

Due (o più) pacchetti da installare dipendono l'uno dall'altro e di conseguenza non possono essere installati. Ciò è probabilmente dovuto ad un errore in uno dei pacchetti nel repositorio di Gentoo. Si prega di effettuare nuovamente la sincronizzazione dopo un po' e riprovare di nuovo. Potrebbe anche essere utile controllare Bugzilla per vedere se il problema è noto e se non lo è, segnalarlo.

Acquisizione fallita

CODE Avvertimento di Portage riguardo un'acquisizione fallita

!!! Acquisizione (fetch) fallita per sys-libs/ncurses-5.4-r5, sto procedendo...
(...)
!!! Alcuni errori di acquidizione sono stati riscontrati. Si prega di leggere i dettagli soprastanti.

Portage non è riuscito a scaricare i sorgenti per una certa applicazione e continuerà ad installare le altre applicazioni (se possibile). Questo fallimento può dipendere da un mirror che non è stato sincronizzato correttamente oppure perché l'ebuild punta ad una posizione non corretta. Il server in cui risiedono i sorgenti può anche essere spento per qualche ragione.

Ritentare dopo un'ora per vedere se il problema persiste.

Protezione del profilo di sistema

CODE Avvertimento di Portage riguardo un pacchetto protetto del profilo

!!! Tentativo di disinstallare uno o più pacchetti del profilo di sistema. 'sys-apps/portage'
!!! Questo potrebbe danneggiare il sistema.

L'utente ha richiesto di rimuovere un pacchetto che è parte dei pacchetti fondamentali del sistema. Esso è elencato nel profilo come necessario, di conseguenza non dovrebbe essere rimosso dal sistema.

Verifica somme di controllo fallita

CODE Fallimento nella verifica delle somme di controllo (digest)

>>> verifica delle somme di controllo delle ebuild
!!! Verifica del compendio (digest) fallita:

Questo indica che qualcosa è andato storto nel repositorio di Gentoo - spesso è dovuto ad un errore di consegna di una ebuild nel repositorio dell ebuild di Gentoo.

Quando la verifica del compendio (digest) fallisce, non si tenti di ricreare il compendio con le somme di controllo personalmente. Eseguire ebuild foo manifest non risolverà il problema; anzi è probabile che peggiorerà la situazione.

Piuttosto, attendere un'ora o due affinché il repositorio si sistemi. È probabile che l'errore sia stato già segnalato, ma la soluzione può impiegare del tempo prima che arrivi nei mirror rsync. Controllare Bugzilla e vedere se qualcuno ha già segnalato il problema o chiedere su #gentoo (webchat) (IRC). Se il problema non è noto, proseguire e presentare istanza del problema per l'ebuild corrotta.

Una volta che l'errore è stato corretto, ri-sincronizzare il repositorio delle ebuild di Gentoo per ottenere il compendio con le somme di controllo revisionato.

Importante
Prestare attenzione a non sincronizzare il repositorio delle ebuild di Gentoo più di una volta al giorno. Come riportato nella politica ufficiale della condotta su Internet (netiquette) di Gentoo (come anche quando si esegue emerge --sync), agli utenti che effettuano la sincronizzazione troppo spesso verrà temporaneamente preclusa la possibilità di farlo per un certo periodo di tempo. Gli utenti che abuseranno di ciò ripetutamente potranno essere bloccati. A meno che non sia assolutamente necessario, spesso è meglio aspettare un periodo di circa 24 ore prima di effettuare nuovamente la sincronizzazione, così che quest'ultima non sovraccarichi i mirror rsync di Gentoo.

Cosa sono le opzioni USE

L'idea dietro alle opzioni USE

Quando si installa Gentoo (o qualunque altra distribuzione, o in generale un sistema operativo) gli utenti compiono scelte a seconda dell'ambiente con cui stanno lavorando. Un'installazione per un server differisce da una per una postazione lavoro. Una stazione da gioco differisce da una per il rendering 3D.

Tutto ciò non solo è vero riguardo alla scelta dei pacchetti da installare, ma anche riguardo alle caratteristiche che un certo pacchetto dovrebbe supportare. Se non c'è bisogno di OpenGL, perché ci si dovrebbe preoccupare di installare e mantenere OpenGL e compilare tutto il suo supporto nella maggior parte dei pacchetti? Se non si desidera usare KDE, perché mai compilare i pacchetti con il supporto a KDE se quei pacchetti funzionano perfettamente senza?

Per aiutare gli utenti a decidere che cosa installare/attivare e che cosa no, Gentoo esige che l'utente definisca il proprio ambiente in modo semplice. Ciò spinge l'utente a stabilire di cosa realmente ha bisogno e facilita il processo affinché Portage possa prendere decisioni utili.

Definizione di un'opzione USE

Inserire le opzioni USE (flag). Una tale opzione è una parola chiave che include il supporto e le informazioni sulle dipendenze per un certo concetto. Se qualcuno specifica una qualche opzione USE, Portage saprà che si desidera il supporto per la parola chiave scelta. Certamente questo modificherà anche le informazioni sulle dipendenze per un pacchetto.

Si dia un'occhiata ad un esempio specifico: la parola chiave kde. Se questa parola chiave non è nella variabile USE, tutti i pacchetti che hanno il supporto opzionale di KDE saranno compilati senza il supporto KDE. Tutti i pacchetti che hanno una dipendenza opzionale da KDE saranno installati senza installare le librerie KDE (come dipendenze). Quando la parola chiave KDE viene specificata, allora quei pacchetti saranno compilati con il supporto a KDE e le librerie KDE saranno installate come dipendenze.

When the kde flag is set to enabled, then those packages will be compiled with KDE support, and the KDE libraries will be installed as dependency.

Definendo correttamente le parole chiave, il sistema sarà adattato in modo specifico alle esigenze dell'utente.

Usare le opzioni USE

Dichiarare opzioni USE permanenti

Come già menzionato, tutte le opzioni USE sono dichiarate nella variabile USE. Per facilitare agli utenti la ricerca e la scelta delle opzioni USE, viene fornita un'impostazione per USE predefinita. Questa impostazione è una raccolta di opzioni USE che si ritiene siano comunemente usate dagli utenti di Gentoo. L'impostazione predefinita è dichiarata nei file make.defaults che fanno parte del profilo selezionato.

Il profilo che il sistema segue è indicato dal link simbolico /etc/portage/make.profile. Ogni profilo funziona sopra gli altri profili e il risultato finale è dunque la somma di tutti i profili. Il profilo più alto è il profilo base (/usr/portage/profiles/base).

Per vedere (interamente) le opzioni USE attive correnti, digitare emerge --info:

root #emerge --info | grep ^USE

USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

Come si può vedere, questa variabile contiene già molte parole chiave. Non si modifichi alcun file make.defaults per adattare la variabile USE alle proprie esigenze personali: i cambiamenti in questi file verrebbero annullati dall'aggiornamento del repositorio di Gentoo!

Per cambiare queste impostazioni predefinite, per aggiungere o rimuovere parole chiavi alla variabile USE. Ciò viene fatto globalmente definendo la variabile USE su /etc/portage/make.conf. In questa variabile uno può aggiungere le opzioni USE aggiuntive richieste, o rimuovere le opzioni USE che non sono più necessarie. Quest'ultima cosa viene fatta mettendo il prefisso segno meno (-) davanti alla parola chiave.

Per esempio, per rimuovere il supporto a KDE e Qt, ma aggiungendo il supporto a LDAP, il seguente USE può essere definito su /etc/portage/make.conf:

FILE /etc/portage/make.confAggiornare USE su make.conf

USE="-kde -qt4 -qt5 ldap"

Dichiarare opzioni USE per singoli pacchetti

Talvolta gli utenti vogliono dichiarare certe opzioni USE per una (o una coppia) di applicazioni, ma non per tutto il sistema. Per soddisfare ciò, modificare /etc/portage/package.use. package.use solitamente è un singolo file, ad ogni modo può anche essere una cartella piena di file figli; vedere il consiglio sottostante e man 5 portage per maggiori informazioni su come usare questa convenzione. I seguenti esempi considerano che package.use sia un singolo file.

Per esempio, per avere solo il supporto Blu-ray nel pacchetto VLC media player (lettore multimediale):

FILE /etc/portage/package.useAbilitare il supporto Blu-ray per VLC

media-video/vlc bluray

Suggerimento
Se package.use pre-esisteva come cartella (contrariamente al singolo file), i pacchetti possono essere modificati con le opzioni USE locali semplicemente attraverso la creazione di file sotto la cartella package.use/. Qualsiasi convenzione di denominazione dei file può funzionare, ma è saggio servirsi di uno schema di denominazione coerente. Per esempio, impostare l'opzione USE bluray localmente per il pacchetto media-video/vlc può essere fatto come segue:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

Analogamente è possibile disabilitare esplicitamente delle opzioni USE per una certa applicazione. Per esempio, per disabilitare il supporto a bzip2 su PHP (pur conservandolo per tutti gli altri pacchetti grazie alla dichiarazione dell'opzione USE su make.conf):

FILE /etc/portage/package.useDisabilitare il supporto bzip2 per PHP

dev-lang/php -bzip2

Dichiarare opzioni USE temporanee

Talvolta gli utenti necessitano di impostare opzioni USE per un breve momento. Anziché modificare /etc/portage/make.conf due volte (per fare e disfare le modifiche su USE) basta dichiarare la variabile USE come variabile di ambiente. Non dimenticare che questa impostazione si applica solo al comando appena inserito; ri-emergere (ri-compilare) o aggiornare questa applicazione (sia esplicitamente che come parte di un aggiornamento di sistema) disferà le modifiche che furono attivate attraverso la (temporanea) definizione delle opzioni USE.

Il seguente esempio rimuove temporaneamente il valore pulseaudio dalla variabile USE in relazione all'installazione di SeaMonkey:

root #USE="-pulseaudio" emerge www-client/seamonkey

Precedenza

Certamente c'è una precedenza che stabilisce quali opzioni hanno la priorità nell'impostazione di USE. La precedenza per l'impostazione di USE è, ordinata secondo priorità (la prima ha priorità più bassa):

1. Impostazione USE predefinita dichiarata nei file make.defaults facenti parte del proprio profilo
2. Impostazione USE definita dall'utente su /etc/portage/make.conf
3. Impostazione USE definita dall'utente su /etc/portage/package.use
4. Impostazione USE definita dall'utente come variabile d'ambiente

Per vedere l'impostazione USE finale così come viene passata a Portage, eseguire emerge --info. Ciò elencherà tutte le variabili rilevanti (inclusa la variabile USE) con la loro attuale definizione così come Portage le riceverà.

root #emerge --info

Adattare l'intero sistema alle nuove opzioni USE

Dopo aver modificato le opzioni USE, il sistema andrebbe aggiornato per riprodurre i necessari cambiamenti. Per fare ciò, usare l'opzione --newuse con emerge:

root #emerge --update --deep --newuse @world

In seguito, eseguire depclean (pulizia profonda) di Portage per rimuovere le dipendenze condizionali che furono compilate con il "vecchio" sistema, ma rese obsolete dalle nuove opzioni USE.

Attenzione
Eseguire emerge --depclean è un'operazione pericolosa e va maneggiata con cautela. Controllare due volte l'elenco fornito dei pacchetti "obsoleti" per essere sicuri di non rimuovere pacchetti necessari. Nel seguente esempio aggiungiamo l'opzione -p per fare in modo che depclean elenchi solo i pacchetti senza rimuoverli:

root #emerge -p --depclean

Quando depclean ha concluso, eseguire revdep-rebuild per ricompilare le applicazioni che sono dinamicamente collegate agli oggetti condivisi forniti dai pacchetti eventualmente rimossi. revdep-rebuild fa parte del pacchetto app-portage/gentoolkit; non dimenticare di compilarlo (emergerlo) per primo.

root #revdep-rebuild

Quando tutto ciò sarà compiuto, il sistema starà usando il nuovo insieme di opzioni USE.

Opzioni USE per specifici pacchetti

Visionare le opzioni USE disponibili

Prendiamo l'esempio di seamonkey: quali opzioni USE è in grado di recepire? Per scoprirlo, usiamo emerge con le opzioni --pretend e --verbose:

root #emerge --pretend --verbose www-client/seamonkey

Questi sono i pacchetti che dovrebbero essere uniti, nell'ordine:
 
Calcolo delle dipendenze... fatto!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Totale: 1 pacchetto (1 nuovo), Grandezza scaricamento: 216,860 KiB

emerge non è il solo strumento per questo lavoro. Infatti, c'è uno strumento dedicato alle informazioni sui pacchetti chiamato equery che risiede nel pacchetto app-portage/gentoolkit

root #emerge --ask app-portage/gentoolkit

Adesso eseguire equery con l'argomento uses per vedere le opzioni USE di un dato pacchetto. Per esempio, con il pacchetto gnumeric:

user $equery --nocolor uses =gnumeric-1.12.31

[ Legend : U - impostazione finale per l'installazione]
[        : I - pacchetto installato con quell'opzione ]
[ Colors : set, unset                                 ]
 * Trovate queste opzioni USE per app-office/gnumeric-1.12.31:
 U I
 + + introspection            : Aggiunge supporto all'introspezione basata su GObject.
 - - libgda                   : Abilita supporto database attraverso gnome-extra/libgda.
 - - perl                     : Abilita il plugin perl loader (caricatore).
 + + python                   : Abilita il plugin python loader (caricatore).
 + + python_targets_python2_7 : Compilato con Python 2.7

Soddisfare le condizioni REQUIRED_USE

Alcune ebuild richiedono o proibiscono certe combinazioni di opzioni USE allo scopo di funzionare appropriatamente. Ciò viene espresso nell'insieme di condizioni collocato nell'espressione REQUIRED_USE. Queste condizioni assicurano che tutte le funzionalità e le dipendenze siano complete e che la compilazione abbia successo e sia eseguita come atteso. Se una di queste condizioni manca, emerge avvertirà l'utente e chiederà di correggere il problema.

Esempio	Descrizione
REQUIRED_USE="foo? ( bar )"	Se foo è impostato, anche bar deve esserlo.
REQUIRED_USE="foo? ( !bar )"	Se foo è impostato, bar non deve esserlo.
REQUIRED_USE="foo? ( || ( bar baz ) )"	Se foo è impostato, bar o baz devono esserlo.
REQUIRED_USE="^^ ( foo bar baz )"	Esattamente uno tra foo bar e baz va impostato.
REQUIRED_USE="|| ( foo bar baz )"	Almeno uno tra foo bar e baz va impostato.
REQUIRED_USE="?? ( foo bar baz )"	Non più di uno tra foo bar e baz va impostato.

Funzionalità di Portage

Portage possiede numerose funzionalità aggiuntive che rendono l'esperienza di Gentoo persino migliore. Molte di queste funzioni dipendono da certi strumenti software che migliorano prestazioni, affidabilità, sicurezza, ...

Per abilitare o disabilitare certe funzionalità di Portage, modificare /etc/portage/make.conf ed aggiornare o impostare la variabile FEATURES che contiene le parole chiave associate alle varie funzionalità, separate da uno spazio bianco. In numerosi casi è anche necessario installare lo strumento aggiuntivo dal quale le funzionalità dipendono.

Non tutte le funzionalità che Portage supporta sono elencate qui. Per una panoramica completa, consultare la pagina manuale make.conf:

user $man make.conf

Per scoprire quali FEATURES (caratteristiche) sono impostate in via predefinita, eseguire emerge --info e cercare la variabile FEATURES o ricavarla con grep:

user $emerge --info | grep ^FEATURES=

Compilazione distribuita

Usare distcc

distcc è un programma per distribuire le compilazioni attraverso molte, non necessariamente identiche, macchine su una rete. Il client (committente) distcc invia tutte le informazioni necessarie ai server (servitori) distcc disponibili (eseguendo distccd), così essi possono compilare parti di codice sorgente per il client. Il risultato con la rete consiste in un tempo di compilazione più veloce.

Più informazioni riguardo distcc (e come averlo in funzione su Gentoo) si trovano nell'articolo Distcc.

Installare distcc

Distcc viene fornito con un monitor grafico per monitorare le attività che il computer sta inviando per la compilazione. Questo strumento è automaticamente installato se sono impostati USE=gnome o USE=gtk.

root #emerge --ask sys-devel/distcc

Attivare il supporto distcc su Portage

Aggiungere distcc alla variabile FEATURES dentro /etc/portage/make.conf. Poi, modificare la variabile MAKEOPTS ed aumentare il numero di attività di compilazione parallele che il sistema permette. Una nota linea guida consiste nell'inserire -jN dove N è il numero dei processori (CPU) che eseguono distccd (incluso l'attuale host) più uno, ma è giusto un'indicazione di massima.

Ora eseguire distcc-config ed inserire l'elenco dei server distcc disponibili. Per fare un semplice esempio, supponiamo che i server DistCC disponibili siano 192.168.1.102 (l'attuale host), 192.168.1.103 e 192.168.1.104 (due host "remoti"):

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Non dimenticare di eseguire anche il servizio distccd (daemon):

root #rc-update add distccd default

root #/etc/init.d/distccd start

Oggetti di compilazione nella cache

Riguardo ccache

ccache è una cache di compilazione veloce. Ogni volta che un'applicazione viene compilata, memorizzerà i risultati intermedi nella cache in modo che, ogni volta che lo stesso programma viene ricompilato, il tempo di compilazione viene notevolmente ridotto. La prima volta che ccache viene eseguito, sarà molto più lento rispeto ad una normale compilazione. Le ricompilazioni successive tuttavia dovrebbero essere più veloci. ccache è utile solo se la stessa applicazione verrà ricompilata molte volte (o se gli aggiornamenti della stessa applicazione si verificano frequentemente); quindi è principalmente utile solo per gli sviluppatori di software.

Per maggiori informazioni su ccache, si visiti la sua homepage.

Attenzione
ccache è nota per causare fallimenti nella compilazione. Talvolta ccache conserverà oggetti di codice obsoleti o file corrotti, che possono impedire la costruzione dei pacchetti. Se ciò succede (errori come "File non riconosciuto: File troncato" compariranno nei build log - registri di compilazione), provare a ricompilare l'applicazione con ccache disabilitata (FEATURES="-ccache" su /etc/portage/make.conf) prima di segnalare un errore (bug report).

Installare ccache

Per installare ccache eseguire il seguente comando:

root #emerge --ask dev-util/ccache

Attivare il supporto ccache su Portage

Aprire /etc/portage/make.conf ed aggiungere ccache a qualsiasi valore definito nella variabile FEATURES. Se FEATURES non esiste, la si crei. Poi, aggiungere una nuova variabile chiamata CCACHE_SIZE (dimensione della cache) ed impostarla con 2G:

FILE /etc/portage/make.confAbilitare il supporto ccache su Portage

FEATURES="ccache"
CCACHE_SIZE="2G"

Per verificare che ccache funzioni, chiedere a ccache di fornire le sue statistiche. Siccome Portage usa una diversa cartella home per ccache, è necessario impostare temporaneamente la variabile CCACHE_DIR:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

La posizione /var/tmp/ccache/ è la cartella home di ccache predefinita di Portage; si può cambiare impostando la variabile CCACHE_DIR su /etc/portage/make.conf.

Eseguendo ccache in modo a sé stante (standalone), verrebbe usato il percorso predefinito ${HOME}/.ccache/, motivo per cui è necessario impostare la variabile CCACHE_DIR quando si richiedono le statistiche ccache (di Portage).

Usare ccache fuori da Portage

Per usare ccache nelle compilazioni non-Portage, aggiungere /usr/lib/ccache/bin/ all'inizio della variabile PATH (prima /usr/bin). Ciò può esser fatto modificando ~/.bash_profile nella cartella home dell'utente. Usare ~/.bash_profile è un modo per definire le variabili PATH (percorso).

FILE ~/.bash_profileImpostare la posizione ccache prima di qualsiasi altra PATH

PATH="/usr/lib/ccache/bin:${PATH}"

Supporto dei pacchetti binari

Creare pacchetti precompilati

Portage supporta l'installazione dei pacchetti precompilati. Anche se Gentoo non fornisce pacchetti precompilati da sé, Portage può essere pienamente consapevole dei pacchetti precompilati.

Per creare un pacchetto precompilato usare il comando quickpkg se il pacchetto è già installato nel sistema, o costruirlo con le opzioni --buildpkg o --buildpkgonly.

Per far sì che Portage crei pacchetti precompilati per ogni singolo pacchetto che viene installato, aggiungere buildpkg alla variabile FEATURES.

Un supporto più ampio nella creazione dei pacchetti precompilati si può ottenere con catalyst. Per maggiori informazioni su catalyst, leggere le FAQ di Catalyst.

Installare i pacchetti precompilati

Sebbene Gentoo non ne fornisce uno, è possibile creare un repositorio centrale dove i pacchetti precompilati vengono depositati. Al fine di usare questo repositorio, è necessario mettere Portage a conoscenza di esso tramite la variabile PORTAGE_BINHOST che dovrà puntare lì. Per esempio, se i pacchetti precompilati stanno su ftp://buildhost/gentoo:

FILE /etc/portage/make.confAggiungere la posizione PORTAGE_BINHOST

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Per installare un pacchetto precompilato, aggiungere l'opzione --getbinpkg al comando emerge accanto all'opzione --usepkg. La prima opzione dice ad emerge di scaricare il pacchetto precompilato dal server precedentemente definito, mentre la seconda chiede ad emerge di provare ad installare il pacchetto precompilato prima di recuperare i sorgenti e compilarlo.

Per esempio, per installare gnumeric con i pacchetti precompilati:

root #emerge --usepkg --getbinpkg gnumeric

Maggiori informazioni sulle opzioni per i pacchetti precompilati di emerge si possono trovare nella pagina manuale di emerge:

user $man emerge

Distribuire pacchetti precompilati ad altri

Se i pacchetti precompilati devono essere distribuiti ad altri, allora ci si assicuri che ciò sia permesso. Per questo si controllino i termini di distribuzione posti all'origine del pacchetto. Per esempio, per un pacchetto rilasciato sotto GNU GPL, i sorgenti vanno resi disponibili insieme ai binari.

Gli ebuild possono definire una restrizione bindist nella loro variabile RESTRICT qualora i binari compilati non fossero distribuibili. Talvolta questa restrizione è condizionale sulla base di una o più opzioni USE.

In via predefinita, Portage non maschererà alcun pacchetto sulla base delle restrizioni. Ciò può essere globalmente modificato impostando la variabile ACCEPT_RESTRICT dentro /etc/portage/make.conf. Per esempio, per nascondere i pacchetti che hanno una restrizione bindist, aggiungere la seguente linea a make.conf:

FILE /etc/portage/make.confAccetta solo pacchetti binari distribuibili

ACCEPT_RESTRICT="* -bindist"

È anche possibile sovrascrivere la variabile ACCEPT_RESTRICT passando l'opzione --accept-restrict al comando emerge. Per esempio, --accept-restrict=-bindist nasconderà temporaneamente i pacchetti con una restrizione bindist.

Si consideri anche l'impostazione della variabile ACCEPT_LICENSE qualora si distribuiscano pacchetti. Vedere la sezione licenze per questo.

Importante
È pienamente responsabilità di ciascun utente conformarsi ai termini della licenza dei pacchetti e alle leggi della nazione dell'utente. Le variabili sui metadati definiti dalle ebuild (RESTRICT o LICENSE) possono fornire indicazioni nel caso in cui la distribuzione dei binari non è consentita, tuttavia l'output di Portage o le domande a cui gli sviluppatori di Gentoo hanno risposto non sono dichiarazioni legali e non dovrebbero essere considerate come tali. Usare prudenza nel rispettare la legge della propria località fisica.

Prelevare i file

Verify distfiles

To re-verify the integrity and (potentially) re-download previously removed/corrupted distfiles for all currently installed packages, run:

root #emerge --ask --fetchonly --emptytree @world

Importante
The contents of this page do not apply to users that chose a systemd profile in Choosing the right profile.

Livelli di esecuzione

Avviare il sistema

Quando il sistema viene avviato, molto testo inizia a scorrere. Quando si presta attenzione, si noterà che quel testo (di solito) è lo stesso ogni volta che si riavvia il sistema. La sequenza di tutte queste azioni è chiamata sequenza di avvio ed è (più o meno) staticamente definita.

Innanzitutto, l'avviatore (bootloader) carica l'immagine del kernel definita nella configurazione del bootloader. Quindi, l'avviatore indica alla CPU di eseguire il kernel. Quando il kernel viene caricato ed eseguito, esso inizializza tutte le strutture e le attività specifiche del kernel ed avvia il processo di init.

Questo processo assicura poi che tutti i filesystem (definiti in /etc/fstab) siano montati e pronti per l'uso. Poi passa ad eseguire i diversi script situati in /etc/init.d/, che avvieranno i servizi necessari affinché il sistema sia avviato correttamente.

Infine, quando tutti gli script sono eseguiti, init attiva i terminali (nella maggior parte dei casi sono console virtuali nascoste e richiamabili con Alt+F1, Alt+F2, ecc.) associandogli un processo speciale chiamato agetty. Questo processo assicurerà poi gli utenti di poter accedere attraverso questi terminali eseguendo il login (accesso).

Gli script di init

Ora init non esegue solamente gli script in /etc/init.d/ a caso. Anzi, nemmeno esegue tutti gli script in /etc/init.d/, ma solo gli script che è stato detto di eseguire. Esso decide quali script eseguire ispezionando il contenuto di /etc/runlevels/.

Per prima cosa, init esegue gli script dentro /etc/init.d/ che hanno collegamenti simbolici con i file in /etc/runlevels/boot/. Solitamente, esso avvierà gli script in ordine alfabetico, ma alcuni script contengono informazioni sulle dipendenze, che dicono al sistema che un altro script deve essere eseguito prima di poter partire.

Quanto tutti gli script con un riferimento su /etc/runlevels/boot/ sono stati eseguiti, init prosegue con gli script che hanno un collegamento simbolico verso /etc/runlevels/default/. Ed ancora, sarà usato l'ordine alfabetico per decidere quale script eseguire prima, a meno che uno script abbia informazioni sulle sue dipendenze, in tal caso l'ordine sarà modificato per fornire una valida sequenza di avvio. Quest'ultima è anche la ragione per cui i comandi usati durante l'installazione di Gentoo Linux usano default, come in rc-update add sshd default.

Come funziona init

Certamente init non decide tutto da solo. Esso necessita di un file di configurazione che specifica quali azioni devono essere compiute. Questo file di configurazione è /etc/inittab.

Tenere a mente la sequenza di avvio che è stata appena descritta - la prima azione di init è montare tutti i filesystem. Ciò viene definito con la seguente linea su /etc/inittab:

FILE /etc/inittabComando di inizializzazione

si::sysinit:/sbin/openrc sysinit

Questa linea dice ad init che deve eseguire /sbin/openrc sysinit per inizializzare il sistema. Lo script /sbin/openrc si prende cura dell'inizializzazione, così uno potrebbe pensare che init non fa molto - esso delega l'attività di inizializzazione del sistema ad un altro processo.

Come seconda cosa, init esegue tutti gli script che hanno collegamenti simbolici dentro /etc/runlevels/boot/. Ciò viene definito con la seguente linea:

FILE /etc/inittabInvocazione del comando di avvio

rc::bootwait:/sbin/openrc boot

Nuovamente, lo script openrc esegue le attività necessarie. Notare che l'opzione data ad openrc (boot) è uguale alla sottodirectory di /etc/runlevels/ che viene usata.

Adesso init controlla il suo file di configurazione per vedere quale livello di esecuzione (runlevel) va eseguito. Per decidere ciò, legge la seguente riga da /etc/inittab:

FILE /etc/inittabSelezione del livello di esecuzione (runlevel) predefinito

id:3:initdefault:

In questo caso (che userà la maggior parte degli utenti Gentoo), l'ID del runlevel è 3. Usando queste informazioni, init controlla cosa deve essere eseguito per avviare il runlevel 3:

FILE /etc/inittabDefinizione dei livelli di esecuzione (runlevel)

l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

La linea che definisce il livello 3, nuovamente, usa lo script openrc per avviare i servizi (ora con argomento default). Ancora una volta si noti che l'argomento openrc è uguale alla sotto cartella in /etc/runlevels/.

Quando openrc finisce, init decide quali console virtuali devono essere attivate e quali comandi devono essere eseguiti su ciascuna console:

FILE /etc/inittabDefinizione dei terminali (console)

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Livelli di esecuzione disponibili

In una sezione precedente, abbiamo visto che init usa uno schema di numerazione per decidere quale livello di esecuzione (runlevel) vada eseguito. Un livello di esecuzione è uno stato nel quale il sistema sta funzionando e contiene una collezione di script (script di runlevel o init script) che devono essere eseguiti quando si entra dentro o si lascia un livello di esecuzione.

In Gentoo, ci sono sette livelli di esecuzione definiti: tre livelli di esecuzione interni, e quattro definiti dall'utente. I livelli di esecuzione interni sono chiamati sysinit, shutdown e reboot e fanno esattamente ciò che i loro nomi implicano: inizializzano il sistema, spengono il sistema e lo riavviano.

I livelli di esecuzione definiti dall'utente sono quelli con una sotto cartella in /etc/runlevels/ di accompagnamento: boot, default, nonetwork e single. Il livello di esecuzione boot avvia tutti i servizi necessari al sistema utilizzati dagli altri livelli di esecuzione. I rimanenti tre livelli differiscono in base ai servizi avviati: default è usato per le operazioni quotidiane, nonetwork è usato nel caso in cui la rete deve risultare sconnessa, e single è usato quando il sistema deve essere riparato.

Lavorare con gli script di init

Gli script che openrc processa all'avvio sono chiamati script di init. Ogni script in /etc/init.d/ può essere eseguito con gli argomenti start, stop, restart, zap, status, ineed, iuse, needsme, usesme, or broken.

Per avviare, fermare o riavviare un servizio (e tutti i servizi dipendenti), si devono usare gli argomenti start, stop, e restart:

root #/etc/init.d/postfix start

Nota
Solo i servizi che necessitano del servizio specificato vengono arrestati o riavviati. Gli altri servizi dipendenti (quelli che usano il servizio ma non ne hanno necessariamente bisogno) non vengono toccati.

Per arrestare un servizio, ma non i servizi che dipendono da esso, usare l'opzione --nodeps insieme all'argomento stop:

root #/etc/init.d/postfix --nodeps stop

Per vedere in quale stato sta un servizio (avviato, arrestato, ...) usare l'argomento status:

root #/etc/init.d/postfix status

Se le informazioni sullo stato mostrano che il servizio è in esecuzione, ma in realtà non lo è, allora reimpostare le informazioni sullo stato su "stopped" con l'argomento zap:

root #/etc/init.d/postfix zap

Per chiedere inoltre quali dipendenze possiede il servizio, usare iuse o ineed. Con ineed è possibile conoscere quali servizi sono effettivamente necessari per il corretto funzionamento del servizio. iuse mostra invece quali servizi possono essere usati dal servizio, ma che non sono necessari al corretto funzionamento.

root #/etc/init.d/postfix ineed

Analogamente, è possibile chiedere quali servizi richiedono il servizio interrogato (needsme) o quali potrebbero usarlo (usesme):

root #/etc/init.d/postfix needsme

Aggiornare i livelli di esecuzione

rc-update

Il sistema init di Gentoo utilizza un albero delle dipendenze per decidere quale servizio vada avviato per primo. Siccome è un compito noioso e non vorremmo che i nostri utenti dovessero farlo manualmente, abbiamo creato strumenti che facilitano l'amministrazione dei livelli di esecuzione (runlevel) e degli script di init.

Con rc-update è possibile aggiungere o rimuovere script di init nei livelli di esecuzione. Lo strumento rc-update chiederà poi automaticamente allo script depscan.sh di ricostruire l'albero delle dipendenze.

Aggiungere e rimuovere servizi

Nelle precedenti istruzioni, gli script di init sono stati già aggiunti al livello di esecuzione "default" (predefinito). Ciò che significa "default" è stato spiegato in precedenza nel documento. Affianco all'argomento runlevel, lo script rc-update richiede un secondo argomento che definisce l'azione: add (aggiungi), del (rimuovi), o show (mostra).

Per aggiungere o rimuovere uno script di init, basta dare a rc-update l'argomento add o del, seguito dallo script di init e dal livello di esecuzione. Per esempio:

root #rc-update del postfix default

Il comando rc-update -v show mostrerà tutti gli script di init disponibili ed elencherà a quali livelli di esecuzione saranno eseguiti:

root #rc-update -v show

È anche possibile eseguire rc-update show (senza -v) per vedere giusto gli script di init abilitati ed i loro livelli di esecuzione.

Configurare i servizi

Perché è necessaria una configurazione aggiuntiva

Gli script di init possono essere piuttosto complessi. Pertanto, non è auspicabile che gli utenti modifichino direttamente gli script di init, in quanto tale azione sarebbe più soggetta ad errori. Tuttavia è importante poter configurare un servizio. Ad esempio, gli utenti potrebbero voler attivare più opzioni per il servizio stesso.

Una seconda ragione per tenere questa configurazione fuori dallo script di init è poter aggiornare gli script di init senza il timore che le modifiche della configurazione dell'utente siano annullate.

La cartella conf.d

Gentoo fornisce un modo facile per configurare tale servizio: ogni script di init che può essere configurato possiede un file dentro /etc/conf.d/. Per esempio, lo script di init apache2 (chiamato /etc/init.d/apache2) ha un file di configurazione chiamato /etc/conf.d/apache2, il quale può contenere le opzioni passate al server Apache 2 quando esso viene avviato:

FILE /etc/conf.d/apache2Opzioni di esempio per lo script di init di apache2

APACHE2_OPTS="-D PHP5"

Questo file di configurazione contiene solo le variabili (proprio come /etc/portage/make.conf), rendendo molto facile configurare i servizi. Esso ci permette anche di fornire più informazioni riguardo le variabili (tramite i commenti).

Scrivere gli script di init

Another useful resource is OpenRC's service script guide.

È necessario?

No, scrivere uno script di init solitamente non è necessario in quanto Gentoo fornisce script di init pronti all'uso per tutti i servizi forniti. Comunque, alcuni utenti potrebbero aver installato un servizio senza usare Portage, in tal caso essi dovranno molto probabilmente creare uno script di init.

Non usare lo script di init fornito dal servizio se esso non è esplicitamente scritto per Gentoo: gli script di init di Gentoo non sono compatibili con gli script di init usati da altre distribuzioni! Così è, eccetto se l'altra distribuzione sta usando OpenRC!

Schema

Di seguito, lo schema base di uno script di init:

CODE Esempio di schema di uno script di init

#!/sbin/openrc-run
  
depend() {
#  (Informazioni sulle dipendenze)
}
  
start() {
#  (Comandi necessari per avviare il servizio)
}
  
stop() {
#  (Comandi necessari per arrestare il servizio)
}

CODE Example initscript layout (updated)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"
 
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
 
depend() {
#  (Dependency information)
}
 
start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

Tutti gli script di init richiedono che la funzione start() sia definita. Tutte le altre sezioni sono opzionali.

Dipendenze

Ci sono due impostazioni similmente capaci di dipendenze che possono essere definite e che influenzano l'avvio o la sequenza degli script di init: use e need. Accanto a questi due, ci sono anche due metodi che influenzano l'ordinamento chiamati before (prima) ed after (dopo). Questi ultimi due non hanno dipendenze se considerati da soli: servono a non far fallire lo script di init originale se quello selezionato non è programmato per avviarsi (o fallisce nell'avvio).

• L'impostazione use informa il sistema di init che tale script usa funzionalità offerte da uno script selezionato, ma non dipende direttamente da esso. Un buon esempio potrebbe essere use logger o use dns. Se quei servizi sono disponibili, verranno usati, ma se il sistema non ha un logger o un server DNS, il servizio continuerà a funzionare. Se i servizi esistono, allora saranno avviati prima che lo script li usi.
• L'impostazione need è una dipendenza rigida. Ciò significa che lo script che dipende da un altro script non sarà avviato finché l'altro script non sarà eseguito con successo. Inoltre, se quell'altro script viene riavviato, allora anche il primo sarà riavviato.
• Quando si usa before, allora lo script selezionato viene eseguito prima, ma solo se quello selezionato è posto nello stesso livello di init. Così uno script di init come xdm che definisce before alsasound avvierà prima lo script alsasound, ma solo se alsasound è programmato per l'avvio nel medesimo livello di init. Se alsasound non è stato programmato per l'avvio, questa particolare impostazione non genera effetti e xdm verrà avviato quando il sistema di init lo riterrà più appropriato.
• Analogamente, after informa il sistema di init che lo script dovrebbe essere eseguito dopo quello selezionato e solo se quello selezionato è posto nello stesso livello di init. Se così non è, allora l'impostazione non genera effetti e lo script verrà avviato quando il sistema di init lo riterrà più appropriato.

Dovrebbe essere chiaro, stando a quanto detto, che need è la sola "vera" impostazione per le dipendenze in quanto determina se lo script sarà avviato o meno. Tutte le altre sono solo puntatori nel sistema di init che chiariscono in quale ordine gli script possono (o dovrebbero) essere eseguiti.

Ora, guardiamo ai tanti script di init disponibili su Gentoo e notiamo che alcuni hanno delle dipendenze da cose che non sono script di init. Queste "cose" si chiamano virtuali.

Una dipendenza dai virtuali è una dipendenza che un servizio fornisce, ma non è fornita solamente da quel servizio. Uno script di init può dipendere da un logger (registratore di eventi) di sistema, ma ci sono molti logger di sistema disponibili (metalogd, syslog-ng, sysklogd, ...). Siccome uno script non può aver bisogno di ciascuno di essi (nessun sistema ragionevole ha tutti questi logger di sistema installati e funzionanti) ci assicuriamo che tutti questi servizi forniscano una dipendenza virtuale.

Per esempio, diamo un'occhiata alle informazioni sulle dipendenze di postfix:

FILE /etc/init.d/postfixInformazioni sulle dipendenze del servizio postfix

depend() {
  need net
  use logger dns
  provide mta
}

Come si può vedere, il servizio postfix:

• Richiede la dipendenza (virtuale) della rete (la quale è fornita, per esempio, da /etc/init.d/net.eth0).
• Usa la dipendenza (virtuale) logger (la quale è fornita, per esempio, da /etc/init.d/syslog-ng).
• Usa la dipendenza (virtuale) dns (la quale è fornita, per esempio, da /etc/init.d/named)
• Fornisce la dipendenza (virtuale) mta (la quale è comune a tutti i server di posta)

Controllare l'ordinamento

Come descritto nella precedente sezione, è possibile dire al sistema di init quale ordine dovrebbe seguire per avviare (o arrestare) gli script. Questo ordinamento è gestito sia attraverso le impostazioni delle dipendenze use (usa) e need (richiedi), ma anche attraverso le impostazione per l'ordine before (prima) ed after (dopo). Così come abbiamo descritto questi, diamo un'occhiata al servizio portmap come esempio per questi script di init.

FILE /etc/init.d/portmapInformazioni sulle dipendenze del servizio portmap

depend() {
  need net
  before inetd
  before xinetd
}

È possibile utilizzare l'asterisco "*" per intercettare tutti i servizi sullo stesso livello di esecuzione (runlevel), sebbene ciò non sia consigliabile.

CODE Usare l'asterisco *

depend() {
  before *
}

Se il servizio deve scrivere sui dischi locali, dovrebbe richiedere localmount. Se si colloca qualsiasi cosa in /var/run/ come file pid, allora dovrebbe avviarsi dopo bootmisc:

CODE Impostazione delle dipendenze con localmount necessario e bootmisc avviato dopo

depend() {
  need localmount
  after bootmisc
}

Funzioni standard

Accanto alla funzione depend(), è necessario definire anche la funzione start(). Questa contiene tutti i comandi necessari per inizializzare il servizio. Si consiglia di utilizzare le funzioni ebegin e eend per informare l'utente su ciò che sta accadendo:

CODE Esempio di funzione start()

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Fai qualcosa nel caso in cui un riavvio richiede più che un arresto; avvia
  fi
  
  ebegin "Avvio di my_service in corso"
  start-stop-daemon --start --exec /percorso/fino_a/il_mio_servizio \
    --pidfile /percorso/fino_a/il_mio_file_pid
  eend $?
}

Sia --exec che --pidfile dovrebbero essere usati nelle funzioni start e stop. Se il servizio non crea un file pid, usare --make-pidfile se possibile, ed è consigliabile verificare che lo crei per essere sicuri. Altrimenti, non si usino file pid. È anche possibile aggiungere --quiet (silenzioso) alle opzioni di start-stop-daemon, ma ciò non è raccomandato a meno che il servizio sia estremamente verboso. L'utilizzo di --quiet può ostacolare l'individuazione di errori (debug) qualora il servizio fallisca l'avvio.

Un'altra rilevante impostazione utilizzata nell'esempio precedente è il controllo del contenuto della variabile RC_CMD. A differenza del precedente sistema di script di init, il nuovo sistema OpenRC non supporta la funzionalità di riavvio specifica per lo script. Piuttosto, lo script deve controllare il contenuto della variabile RC_CMD per vedere se una funzione (come start() o stop()) vada invocata o meno come parte del riavvio.

Nota
Assicurarsi che --exec chiami effettivamente un servizio e non solamente uno script della shell che lancia dei servizi ed esce - ovvero quel che si suppone faccia lo script di init.

Per avere più esempi sulla funzione start(), si legga il codice sorgente degli script di init disponibili nella cartella /etc/init.d/.

Un'altra funzione che può (anche se non deve) essere definita è stop(). Il sistema di init è abbastanza intelligente da compilare questa funzione da solo se viene usato start-stop-daemon.

CODE Esempio di funzione stop()

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Se il servizio esegue qualche altro script (per esempio, Bash, Python, o Perl) e questo script in seguito cambia i nomi (ad esempio, da foo.py a foo), allora è necessario aggiungere --name a start-stop-daemon. Si deve specificare il nome con cui verrà modificato lo script. In questo esempio, un servizio avvia foo.py, il quale cambia i nomi in foo:

CODE Esempio di definizione per un servizio che avvia lo script foo

start() {
  ebegin "Avvio di my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

start-stop-daemon mette a disposizione un'eccellente pagina manuale se maggiori informazioni sono necessarie:

user $man start-stop-daemon

La sintassi degli script di init di Gentoo si basa sulla shell POSIX, così le persone sono libere di usare costrutti sh-compatibili all'interno dei loro script di init. Si evitino altri costrutti, come quelli specifici di bash, negli script di init per essere sicuri che gli script rimangano funzionanti indipendentemente dai cambiamenti che Gentoo potrebbe ricevere al suo sistema di init.

Aggiungere opzioni personalizzate

Se lo script di init necessita di supportare più opzioni di quelle già incontrate, si aggiunga l'opzione alla variabile extra_commands e si crei una funzione con lo stesso nome dell'opzione. Ad esempio, per supportare un'opzione chiamata restartdelay (riavvio con ritardo):

• extra_commands - Command is available with the service in any state
• extra_started_commands - Command is available when the service is started
• extra_stopped_commands - Command is available when the service is stopped

CODE Definizione di esempio del metodo restartdelay

extra_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # Aspetta 3 secondi prima di ripartire
  start
}

Importante
La funzione restart() non può essere sovra-definita (override) in OpenRC!

Variabili di configurazione del servizio

Per supportare i file di configurazione in /etc/conf.d/, non è necessario implementare specifiche: quando viene eseguito lo script di init, i seguenti file vengono automaticamente acquisiti (ovvero le variabili sono disponibili per l'uso):

• /etc/conf.d/IL_TUO_SCRIPT_DI_INIT
• /etc/conf.d/basic
• /etc/rc.conf

Inoltre, se lo script di init fornisce una dipendenza virtuale (come net), verrà generato anche il file (come /etc/conf.d/net) associato a tale dipendenza.

Modificare il comportamento dei runlevel

Chi potrebbe beneficiarne

Molti utenti di portatili conoscono tale situazione: a casa hanno bisogno di avviare net.eth0, ma non vogliono avviare net.eth0 mentre sono in viaggio (dato che non ci sarà una rete disponibile). Con Gentoo il comportamento del livello di esecuzione (runlevel) può essere modificato a piacere.

Per esempio, è possibile creare un secondo livello di esecuzione (runlevel) "predefinito" che può essere avviato con altri script di init ad esso assegnati. Al momento dell'avvio, l'utente può quindi selezionare il livello di esecuzione predefinito da utilizzare.

Usare softlevel

Prima di tutto, creare la cartella del livello di esecuzione per il secondo livello "predefinito". Ad esempio, creiamo il livello di esecuzione "offline":

root #mkdir /etc/runlevels/offline

Aggiungere gli script di init necessari al livello di esecuzione appena creato. Ad esempio, per avere una copia esatta del livello di esecuzione corrente predefinito, ma senza net.eth0:

root #cd /etc/runlevels/default

root #for service in *; do rc-update add $service offline; done

root #rc-update del net.eth0 offline

root #rc-update show offline

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Anche se net.eth0 è stato rimosso dal livello di esecuzione offline, udev potrebbe tentare di avviare qualsiasi dispositivo rilevato ed avviare i servizi appropriati, una funzionalità chiamata hotplugging (collegamento "a caldo"). Per impostazione predefinita, Gentoo non abilita l'hotplugging.

Per abilitare l'hotplugging, ma solo per un insieme di script selezionati, usare la variabile rc_hotplug in /etc/rc.conf:

FILE /etc/rc.confAbilitare l'hotplugging dell'interfaccia WLAN

rc_hotplug="net.wlan !net.*"

Nota
Per maggiori informazioni sui servizi avviati dal dispositivo, vedere i commenti all'interno di /etc/rc.conf.

Modificare la configurazione dell'avviatore (bootloader) e aggiungere una nuova voce per il livello di esecuzione (runlevel) offline. Per quella voce, aggiungere softlevel=offline come parametro di avvio.

Usare bootlevel

Usare il livello di avvio (bootlevel) è del tutto analogo al livello soft (softlevel). L'unica differenza qui è che viene definito un secondo livello di esecuzione "di avvio" ("boot" runlevel) invece di un secondo livello di esecuzione "predefinito" ("default" runlevel).

Variabili d'ambiente

Introduzione

Una variabile d'ambiente è un oggetto denominato che contiene informazioni utilizzate da una o più applicazioni. Molti utenti (e specialmente quelli nuovi su Linux) lo trovano un po' strano o ingestibile. Tuttavia, questo è un errore: utilizzando le variabili d'ambiente si può facilmente modificare un'impostazione di configurazione per una o più applicazioni.

Esempi importanti

La seguente tabella elenca numerose variabili usate da un sistema Linux descrivendone il loro uso. Dopo la tabella vengono presentati dei valori di esempio.

Variabile	Descrizione
PATH	Questa variabile contiene un elenco di cartelle separate dai due punti in cui il sistema cercherà i file eseguibili. Se viene inserito il nome di un eseguibile (come ls, rc-update o emerge) ma questo eseguibile non si trova in una delle cartelle elencate, allora il sistema non lo eseguirà (a meno che non venga immesso il percorso completo nel comando, come /bin/ls).
ROOTPATH	Questa variabile ha la stessa funzione di PATH, ma elenca solo le cartelle che andranno controllate quando l'utente root (radice) immette un comando.
LDPATH	Questa variabile contiene un elenco di cartelle separate dai due punti in cui il linker dinamico cerca per trovare una libreria.
MANPATH	Questa variabile contiene un elenco di cartelle separate dai due punti in cui il comando man cerca le pagine man (manuale).
INFODIR	Questa variabile contiene un elenco di cartelle separate dai due punti in cui il comando info cerca le pagine di informazione.
PAGER	Questa variabile contiene il percorso al programma usato per elencare il contenuto dei file (come less o more).
EDITOR	Questa variabile contiene il percorso al programma utilizzato per modificare il contenuto dei file (come nano o vi).
KDEDIRS	Questa variabile contiene un elenco di cartelle separate dai due punti che contengono materiale specifico per KDE.
CONFIG_PROTECT	Questa variabile contiene un elenco di cartelle delimitate da spazi che saranno protette da Portage durante gli aggiornamenti.
CONFIG_PROTECT_MASK	Questa variabile contiene un elenco di cartelle delimitate da spazi che non saranno protette da Portage durante gli aggiornamenti.

Di seguito è riportato un esempio di definizione per tutte queste variabili:

CODE Impostazioni di esempio per le variabili citate

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"

Definire le variabili globalmente

La cartella env.d

Per centralizzare le definizioni di queste variabili, Gentoo ha introdotto la cartella /etc/env.d/. All'interno di questa cartella sono disponibili numerosi file, come 00basic, 05gcc, ecc., che contengono le variabili necessarie all'applicazione menzionata nel nome stesso del file.

Per esempio, quando gcc risulta installato, un file chiamato 05gcc è stato creato da ebuild, il quale contiene le definizioni delle seguenti variabili:

FILE /etc/env.d/05gccVariabili d'ambiente predefinite abilitate per gcc

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

Altre distribuzioni potrebbero indicare ai loro utenti di modificare o aggiungere queste variabili d'ambiente su /etc/profilo o su altre posizioni. Gentoo, d'altro canto, rende facile per l'utente (e per Portage) mantenere e gestire le variabili d'ambiente senza dover prestare attenzione ai numerosi file che possono contenere queste variabili d'ambiente.

Per esempio, quando gcc viene aggiornato, il file /etc/env.d/05gcc viene anch'esso aggiornato senza chiedere alcuna interazione da parte dell'utente.

Questo non solo avvantaggia Portage, ma anche l'utente. Occasionalmente agli utenti potrebbe venir chiesto di impostare una determinata variabile d'ambiente a livello di sistema. Ad esempio, prendiamo la variabile http_proxy. Anziché mettere in disordine /etc/profile, gli utenti possono ora semplicemente creare un file (per esempio /etc/env.d/99local) ed inserirci le definizioni:

FILE /etc/env.d/99localImpostare una variabile globale

http_proxy="proxy.server.com:8080"

Utilizzando lo stesso file per tutte le variabili autogestite, gli utenti hanno una rapida panoramica sulle variabili che loro stessi hanno definito.

env-update

Svariati file in /etc/env.d/ definiscono la variabile PATH. Questo non è un errore: quando viene eseguito il comando env-update, esso aggiungerà le varie definizioni prima di aggiornare le variabili d'ambiente, rendendo così facile per i pacchetti (o gli utenti) aggiungere la propria impostazione delle variabile d'ambiente senza interferire con i valori preesistenti.

Lo script env-update aggiungerà i valori secondo l'ordine alfabetico dei file /etc/env.d/. I nomi dei file devono iniziare con due cifre decimali.

CODE Ordine di aggiornamento utilizzato da env-update

00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

Non sempre avviene la concatenazione di variabili, solo con le seguenti variabili: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH, and PYTHONPATH. Per tutte le altre variabili viene usato il valore definito per ultimo (secondo l'ordine alfabetico dei file in /etc/env.d/).

È possibile aggiungere più variabili a questo elenco di variabili concatenate, aggiungendo il nome della variabile nella variabile COLON_SEPARATED o in SPACE_SEPARATED (anche all'interno di un file in /etc/env.d/).

Quando si esegue env-update, lo script creerà tutte le variabili d'ambiente e le posizionerà in /etc/profile.env (usato da /etc/profile). Esso estrae anche le informazioni dalla variabile LDPATH e le usa per creare /etc/ld.so.conf. Dopo ciò, verrà eseguito ldconfig per ricreare il file /etc/ld.so.cache usato dal linker (collegatore) dinamico.

Per vedere l'effetto di env-update immediatamente dopo averlo eseguito, eseguire il seguente comando per aggiornare l'ambiente. Gli utenti che hanno già installato autonomamente Gentoo probabilmente lo ricorderanno dalle istruzioni di installazione:

root #env-update && source /etc/profile

Nota
Il comando precedente aggiorna solo le variabili nel terminale corrente, nei nuovi terminali aperti e nei terminali "figlio". Quindi, se l'utente sta lavorando in X11, deve digitare source /etc/profile su ogni nuovo terminale aperto o riavviare X così che tutti i nuovi terminali generino le nuove variabili. Se viene utilizzato un gestore di login, è necessario diventare root e riavviare il servizio /etc/init.d/xdm.

Importante
Non è possibile utilizzare le variabili della shell quando si definiscono altre variabili. Ciò significa che cose come FOO="$BAR" (dove $BAR è un'altra variabile) vengono proibite.

Definire le variabili localmente

Specifico per l'utente

Potrebbe non essere necessario definire a livello globale una variabile d'ambiente. Per esempio, si potrebbe voler aggiungere la cartella /home/my_user/bin e la cartella di lavoro corrente (quella in cui si trova l'utente) alla variabile PATH, ma senza che gli altri utenti sul sistema abbiano questa impostazione nella loro variabile PATH. Per definire localmente una variabile d'ambiente, usare ~/.bashrc o ~/.bash_profile:

FILE ~/.bashrcEstendere PATH per un uso locale

# I due punti non seguiti da alcuna cartella vengono considerati come cartella di lavoro corrente
PATH="${PATH}:/home/my_user/bin:"

Dopo il logout/login (sconnessione e riconnessione), la variabile PATH verrà aggiornata.

Specifico per la sessione

Talvolta vengono richieste definizioni anche più rigide. Per esempio, un utente potrebbe voler essere in grado di utilizzare i binari da una cartella temporanea creata senza utilizzare il percorso dei binari stessi o modificando ~/.bashrc per il breve tempo necessario.

In questo caso, basta definire la variabile PATH nella sessione corrente usando il comando export. Finché l'utente non si disconnette, la variabile PATH utilizzerà le impostazioni temporanee.

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"