Lavorare con Gentoo

Portage è probabilmente l'innovazione di Gentoo più rilevante nella gestione software. La grande flessibilità e l'enorme quantità di caratteristiche ne fanno uno dei migliori programmi per la gestione del software disponibili per Linux.

Portage è completamente scritto in Python e Bash e perciò completamente visibile agli utenti essendo entrambi linguaggi di scripting.

Molti utenti useranno Portage attraverso il tool emerge. Questo capitolo non è un duplicato delle informazioni disponibili attraverso le pagine man di emerge. Per avere la lista completa delle opzioni di emerge, consultare la pagina man:

 

# man emerge

Quando si parla di pacchetti si intendono spesso titoli software che sono disponibili agli utenti Gentoo attraverso l'albero del Portage. L'albero del Portage è una collezione di file ebuild che contengono tutte le informazioni necessarie al Portage per manutenere il software (installare, ricercare,....). Questi ebuild risiedono di default in /usr/portage.

Ogni qualvolta si chiede al Portage di eseguire alcune azioni riguardanti i titoli software, vengono usati gli ebuild del sistema come base. Diviene, così, importante aggiornare regolarmente gli ebuild del sistema in modo tale che Portage sia a conoscenza del nuovo software, degli aggiornamenti, ecc.

L'albero del Portage viene di solito aggiornato con rsync, una utility per il trasferimento incrementale di file. L'aggiornameto è realmente semplice dato che il comando emerge fornisce un'interfaccia per rsync:

 

# emerge --sync

Se non si riesce ad usare rsync a causa di un firewall si può aggiornare l'albero del Portage usando lo snapshot che viene generato giornalmente. Il tool emerge-webrsync scarica ed installa automaticamente l'ultimo snapshot dai sistemi Gentoo.

 

# emerge-webrsync

La ricerca dei titoli software attraverso l'albero del Portage si esegue utilizzando la funzione di ricerca di emerge. Di default emerge --search restituisce i nomi dei pacchetti i cui titoli corrispondono (per intero o parzialmente) a quelli forniti per la ricerca.

Per esempio, dovendo cercare tutti i pacchetti che hanno "pdf" nel loro nome:

 

$ emerge --search pdf

Se si vuole cercare attraverso la descrizione si può usare l'opzione --searchdesc ( o -S):

 

$ emerge --searchdesc pdf

Da uno sguardo all'output si nota che vengono fornite diverse informazioni. I campi sono chiaramente identificati così che non saranno esaminati:

 

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Una volta trovato il titolo del software che interessa, lo si può facilmente installare con emerge facendolo seguire dal nome del pacchetto. Per esempio, per installare gnumeric:

 

# emerge gnumeric

Dato che molte applicazioni dipendono da altre ogni tentativo di installare certi pacchetti software potrebbe portare all'installazione di alcuni pacchetti aggiuntivi. Se si vuol sapere cosa verrà installato dal Portage quando viene richiesta un'installazione, si deve aggiungere l'opzione --pretend. Per esempio:

 

# emerge --pretend gnumeric

Quando si chiede al Portage di installare un pacchetto, verrà scaricato il codice sorgente necessario da internet e memorizzato di default in /usr/portage/distfiles. Il pacchetti verrà quindi scompresso, compilato e installato. Se si vuole che Portage scarichi solo i sorgenti senza installarli, si aggiunga al comando emerge l'opzione --fetchonly:

 

# emerge --fetchonly gnumeric

Se si vuole rimuovere un pacchetto dal sistema, usare emerge --unmerge. Questo comando rimuoverà tutti i file installati dal pacchetto eccetto i file di configurazione che sono stati alterati dopo l'installazione. In questo modo si permette di continuare a lavorare con il pacchetto nel caso si decidesse di installarlo nuovamente.

	Attenzione
	Portage non controllerà se il pacchetto che si vuole rimuovere sia richiesto da un altro pacchetto. Verrà solo emesso un avviso del fatto che la rimozione di pacchetti importanti potrebbe danneggiare il sistema.

 

# emerge --unmerge gnumeric

Quando si rimuove un pacchetto dal sistema, le sue dipendenze saranno lasciate. Per far trovare al Portage tutte le dipendenze che potrebbero essere rimosse, usare la funzionalità --depclean di emerge. Se ne parlerà in seguito.

Per mantenere il sistema in perfetta forma (e non solo con gli ultimi aggiornamenti sulla sicurezza) si dovrà mantenere aggiornato il sistema regolarmente. Dato che Portage controlla gli ebuild dell'albero del Portage si dovrà prima aggiornare l'albero. Quindi, si potrà aggiornare il sistema con emerge --update world:

 

# emerge --update world

Portage cercherà quindi le nuove versioni delle applicazioni installate. Verranno comunque verificate solo le versioni per le applicazioni che si sono esplicitamente installate e non le dipendenze. Se si vuole aggiornare ogni singolo pacchetto del sistema, occorre aggiungere l'argomento --deep:

 

# emerge --update --deep world

Se è stato alterato qualche USE flag si può aggiungere l'opzione --newuse. Portage verificherà se la modifica richiede l'installazione di nuovi pacchetti o la ricompilazione di quelli esistenti:

 

# emerge --update --deep --newuse world

Alcuni pacchetti presenti nell'albero del Portage non hanno un contenuto reale ma sono usati per installare una collezione di pacchetti. Per esempio, il pacchetto kde installa un ambiente KDE sul sistema ricercando tra i vari pacchetti legati al KDE come dipendenze.

La rimozione di un tale pacchetto dal sistema usando emerge --unmerge, non avrà successo dato che le numerose dipendenze rimarranno sul sistema.

Portage ha anche la funzionalità di rimozione delle dipendenze orfane, ma dato che la disponibilità del software è dinamicamente dipendente, occorre prima aggiornare completamente l'intero sistema, includendo, se ci sono state, le modifiche alle flag USE. Quindi sarà possibile eseguire emerge --depclean per rimuovere le dipendenze orfane. Fatto ciò, ci sarà bisogno di ricompilare le applicazioni che erano dinamicamente linkate al software rimosso ma non più richiesto.

Tutto ciò può essere fatto con un seguenti tre comandi:

 

# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild

revdep-rebuild viene provveduto col pacchetto gentoolkit, che deve essere quindi emerso prima:

 

# emerge gentoolkit

Portage è estremamente potente e supporta molte caratteristiche che altri gestori di software omettono. Si vedranno ora altri aspetti del Portage senza andare troppo nei dettagli.

Portage permette la coesistenza di differenti versioni dello stesso pacchetto. A differenza di altre distribuzioni che tendono a chiamare i propri pacchetti con le versioni (come freetype e freetype2), Portage usa una tecnica chiamata SLOT. Un ebuild dichiara un certo SLOT per le proprie versioni. Ebuild con SLOT differenti possono coesistere sullo stesso sistema. Per esempio, il pacchetto freetype ha un ebuild con SLOT="1" e SLOT="2".

Ci sono anche pacchetti che provvedono la stessa funzionalità ma con un'implementazione diversa. Per esempio, metalogd, sysklogd e syslog-ng, tutti gestori di eventi di sistema. Applicazioni che fanno assegnamento sulla disponibilità di un gestore di eventi di sistema, non possono dipendere da uno in particolare. Per esempio, metalogd, come altri sistemi di gestione di eventi, sono tutti un'ottima scelta. Portage permette l'uso di virtualità: ogni sistema di gestione degli eventi provvede un virtual/syslog in modo tale che le applicazioni possano dipendere da tale virtual/syslog.

Il software all'interno dell'albero del Portage, può risiedere in differenti branche. Di default il sistema accetta solo pacchetti che Gentoo giudica stabili. Molti nuovi software una volta raccomandati, vengono aggiunti ad una branca di test, il che significa che sarà necessario procedere ad ulteriori verifiche prima di marcarli come stabili. Anche se gli ebuild per tali software sono presenti nell'albero del Portage, non vengono aggiornati prima di raggiungere la branca stabile.

Alcuni software sono disponibili solo per alcune architetture. Oppure il software non gira su altre architetture o ha necessità di essere ulteriormente testato o gli sviluppatori che raccomandano il software non sono in grado di verificare se il pacchetto gira su differenti architetture.

Ogni installazione di Gentoo aderisce ad un certo profilo che contiene tra le altre informazioni, la lista dei pacchetti che sono richiesti affinché un sistema funzioni normalmente.

 

[blocks B     ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0)

 

!!! Error: the gnome-base/bonobo-activation package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers. 

Gli ebuild contengono specifici campi che informano il Portage sulle dipendenze. Ci sono due possibili dipendenze: dipendenze in fase di compilazione dichiarate in DEPEND e dipendenze per l'esecuzione dichiarate in RDEPEND. Quando una di queste dipendenze marca un pacchetto o un virtuale come non compatibile, questo viene bloccato.

Per correggere il blocco, si può scegliere tra il non installare il pacchetto o rimuovere prima il pacchetto che causa il conflitto. Nel precedente esempio si può scegliere tra il non installare libbonobo o rimuovere prima bonobo-activation.

 

!!! all ebuilds that could satisfy "bootsplash" have been masked. 

 

!!! possible candidates are:

- 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)
- media-video/ati-gatos-4.3.0 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)

Quando si desidera installare un pacchetto che non è disponibile per il nostro sistema, si riceverà un errore di pacchetto mascherato. Si dovrà quindi installare un'applicazione differente disponibile per il nostro sistema oppure aspettare finché il pacchetto divenga disponibile. C'è sempre una ragione perché un pacchetto viene mascherato:

 

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r4
!!! Possibly a DEPEND/*DEPEND problem. 

L'applicazione che si sta provando ad installare dipende da un altro pacchetto che non è disponibile per il sistema. Controllare su bugzilla se la cosa è segnalata altrimenti la si può riportare. A meno che non si stia mescolando le branche, questo non dovrebbe accadere ed è perciò un bug.

 

!!! The short ebuild name "aterm" is ambiguous.  Please specify
!!! one of the following fully-qualified ebuild names instead:

    dev-libs/aterm
    x11-terms/aterm

L'applicazione che si vuole installare ha un nome che corrisponde con un altro pacchetto. Occorre specificare la categoria. Portage informa sulle scelte possibili.

 

!!! Error: circular dependencies: 

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 

Due (o più) pacchetti che si vuole installare dipendono l'uno dall'altro e non possono perciò essere installati. Questo è probabilmente un bug del Portage. Provare ad eseguire un rsync e provare nuovamente. Si può anche controllare su bugzilla se è un caso conosciuto oppure no, nel qual caso lo si può riportare.

 

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Portage non è riuscito a scaricare i sorgenti per una data applicazione e proverà a proseguire con l'installazione delle altre applicazioni se ci sono. Questo problema può essere causato da un mirror che non è stato sincronizzato appropriatamente o perché l'ebuild punta ad una locazione incorretta. Il server dove risiedono i sorgenti potrebbe anche non essere disponibile per qualche ragione.

Riprovare dopo un'ora e vedere se la situazione persiste.

 

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

Si è richiesto la rimozione di un pacchetto che fa parte del core del sistema. Tale pacchetto è listato nel vostro profile come richiesto e dovrebbe perciò non essere rimosso dal sistema.

Durante l'installazione di Gentoo (o di altre distribuzioni o comunque di altri sistemi operativi), sono possibili diverse scelte a seconda dell'ambiente di lavoro. Le impostazioni per un server differiscono da quelle per una workstation, così come una stazione per giocare differisce da una per il rendering 3D.

Questo non è vero soltanto per la scelta dei pacchetti da installare, ma anche per le caratteristiche che un certo pacchetto dovrebbe supportare. Per esempio, se l'uso delle OpenGL non è richiesto, non dovrebbe essere necessario né preoccuparsi di installare le OpenGL nè tantomento abilitarne il supporto nei pacchetti che ne farebbero uso. Per lo stesso motivo, se non vogliamo usare il KDE, non vorremmo neanche preoccuparci di compilare i pacchetti col supporto per il KDE se questi pacchetti funzionano tranquillamente senza.

Per aiutare gli utenti a decidere cosa installare/attivare e cosa no, è necessario che l'utente specifichi il proprio ambiente nel modo più semplice. Questo forza l'utente a decidere cosa desidera realmente e facilita Portage, il sistema per la gestione dei pacchetti, a prendere le decisioni appropriate.

Concettualmente un flag USE è una parola chiave che racchiude l'idea di supporto e di informazione sulla dipendenza. Se si definisce un certo flag USE, si indica al Portage la volontà di avere il supporto per la parola chiave scelta. Questo, naturalmente, altera anche le informazioni sulle dipendenze per un dato pacchetto.

Prendiamo un esempio specifico: la parola chiave kde. Se questa parola chiave non è presente nella variabile USE, tutti i pacchetti che hanno il supporto opzionale per il KDE vengono compilati senza tale supporto. Di conseguenza tutti i pacchetti cha hanno una dipendenza opzionale con KDE vengono installati senza le relative librerie KDE. Se invece la parola chiave kde è stata definita, questi pacchetti vengono compilati col supporto del KDE e di conseguenza anche le sue librerie vengono installate come dipendenze.

La conseguenza di una corretta definizione delle parole chiave, è di avere un sistema configurato specificamente per le proprie necessità.

Ci sono due tipi di flag USE: globali e locali.

Una lista di flag USE globali disponibile può essere trovata online o localmente in /usr/portage/profiles/use.desc. Segue un estratto molto incompleto:

gtk     - Aggiunge il supporto per x11-libs/gtk+ (Il GIMP Toolkit)
gtk2    - Usa gtk+-2.0.0 invece di  gtk+-1.2 nel caso dei programmi che hanno il supporto per entrambe.
gtkhtml - Aggiunge il supporto per gnome-extra/gtkhtml
guile   - Aggiunge il supporto per dev-util/guile (interprete per Scheme)
icc     - Usa il compilatore  Intel C++ Compiler se il pacchetto lo supporta
icc-pgo - Abilita la generazione di dati PGO o usare insieme a icc
imap    - Aggiunge il  supporto per IMAP

Un elenco delle flag USE locali disponibili può essere trovato in /usr/portage/profiles/use.local.desc.

Seguono le informazioni su come dichiarare i flag USE in modo permanente.

Come precedentemente menzionato, tutti i flag USE sono dichiarati attraverso la variabile USE. Per facilitare la ricerca e la scelta dei flag USE, viene fornita una configurazione USE predefinita. Questa configurazione è una collezione di flag USE che dovrebbe essere comunemente usata dagli utenti Gentoo ed è dichiarata nel file /etc/make.profile/make.defaults. Segue la configurazione predefinita:

USE="x86 oss apm arts avi berkdb crypt cups encode foomaticdb gdbm gif gpm
 gtk gtk2 imlib jpeg kde gnome libg++ libwww mad mikmod motif mpeg ncurses
 nls oggvorbis opengl pam pdflib png python qt quicktime readline sdl
 slang spell ssl svga tcpd truetype X xml2 xmms xv zlib"

Come è evidente, questa variabile contiene già una serie di parole chiave. Non alterare il file /etc/make.profile/make.defaults per adattare la variabile USE alle proprie necessità dato che le modifiche a questo file vengono sovrascritte ad ogni aggiornamento del Portage.

Per cambiare la configurazione predefinita, è necessario aggiungere o rimuovere parole chiave dalla variabile USE e può essere fatto globalmente definendo la variabile USE nel file /etc/make.conf. In questa variabile è possibile aggiungere flag USE extra, richiesti o rimuoverne di non richiesti nel qual caso occorre anteporre alla parola chiave il segno meno ("-").

Per esempio, per rimuovere il support per KDE e QT ed aggiungere il supporto per ldap, può essere definita la seguente dichiarazione USE in /etc/make.conf:

USE="-kde -qt ldap"

Qualche volta si desidera dichiarare una determinata flag USE per una (o per più) applicazione ma non per tutto il sistema. Per fare questo, si deve creare la directory /etc/portage (se ancora non esiste) e modificare /etc/portage/package.use.

Per esempio, se non si vuole che berkdb sia supportato globalmente, ma si desidera per mysql, si dovrebbe aggiungere:

dev-db/mysql berkdb

Si possono naturalmente anche disabilitare le flag USE per una certa applicazione. Per esempio, se non si desidera il supporto java in PHP:

dev-php/php -java

In certi casi è utile dichiarare flag USE una sola volta. Invece di editare /etc/make.conf due volte (una per la modifica e l'altra per riportare il tutto all'origine) è possibile dichiarare la variabile USE come fosse una variabile ambiente. Si ricordi che, quando si ri-emerge o si aggiorna questa applicazione (in modo esplicito o parte di un aggiornamento del sistema), i cambiamenti saranno persi!

Segue un esempio di come rimuovere temporaneamente il supporto java durante l'installazione di mozilla.

# USE="-java" emerge mozilla

Alcuni pacchetti non solo si aspettano flag USE ma ne forniscono a loro volta. Quando uno di questi viene installato, il flag USE che è fornito viene aggiunto alla configurazione di USE. Per avere la lista dei pacchetti che aggiungono flag USE, fare riferimento al file /etc/make.profile/use.defaults:

gnome           gnome-base/gnome
gtk             x11-libs/gtk+
qt              x11-libs/qt
kde             kde-base/kdebase
motif           x11-libs/openmotif

Naturalmente esiste un ordine definito riguardante quali dichiarazioni abbiano la priorità nelle configurazioni USE. Non è necessario dichirare USE="-java" solo per vedere se "java" è usato comunque, ecco l'ordine di precedenza per la configurazione USE (i primi hanno la priorità più bassa):

Per vedere la configurazione finale di USE che viene usata dal Portage, eseguire emerge info che visualizzerà una lista di tutte le variabili rilevanti (incluso la variabile USE) col valore usato dal Portage.

 

# emerge info

Se si sono cambiate le proprie flag USE e si desidera aggiornare l'intero sistema, affinchè utilizzi le nuove flag USE, si può usare l'opzione --newuse di emerge:

 

# emerge --update --deep --newuse world

Dopo, eseguire il depclean del Portage per rimuovere le dipendenze condizionali che erano state emerse nel vecchio sistema, ma che sono diventate obsolete con l'uso delle nuove flag USE.

	Attenzione
	Eseguire emerge depclean è una operazione pericolosa e dovrebbe essere fatta con cura. Si ricontrolli la lista fornita di pacchetti "obsoleti" per assicurarsi che non si rimuovano pacchetti di cui si ha bisogno. Nell'esempio seguente si è aggiunto -p per avere solo la lista dei pacchetti senza rimuoverli.

 

# emerge -p depclean

Quando il depclean ha finito, eseguire revdep-rebuild per ricompilare le applicazioni che sono collegate agli oggetti forniti dai pacchetti rimossi. revdep-rebuild è parte del pacchetto gentoolkit; non dimenticarsi di emergerlo prima.

 

# revdep-rebuild

Quando tutto è finito, il sistema userà le nuove flag USE.

Ecco l'esempio di mozilla per vedere quali flag si aspetta. Per questo usare emerge con le opzioni --pretend e --verbose:

 

# emerge --pretend --verbose mozilla
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] net-www/mozilla-1.5-r1 +java +crypt -ipv6 -gtk2 +ssl +ldap 
+gnome -debug +mozcalendar -mozaccess -mozxmlterm -moznoirc -moznomail
-moznocompose -moznoxft 

emerge non è il solo strumento che fa questo, infatti ci sono strumenti dedicati alla gestione delle informazioni sui pacchetti come etcat che fa parte del pacchetto gentoolkit. Occorre prima installare gentoolkit:

 

# emerge gentoolkit

Ora è possibile usare etcat con l'argomento uses per avere la lista dei flag USE usati da un dato pacchetto. Ad esempio per il pacchetto gnumeric:

 

# etcat uses gnumeric
[ Colour Code : set unset ]
[ Legend      : (U) Col 1 - Current USE flags        ]
[             : (I) Col 2 - Installed With USE flags ]

 U I [ Found these USE variables in : app-office/gnumeric-1.2.0 ]
 - - libgda  : Adds GNU Data Access (CORBA wrapper) support for gnumeric
 - - gnomedb : unknown
 + + python  : Adds support/bindings for the Python language
 + + bonobo  : Adds support for gnome-base/bonobo (Gnome CORBA interfaces)

Portage ha molte altre caratteristiche che rendono Gentoo ancora migliore. Molte di queste comprendono tool software che migliorano le prestazioni, l'affidabilità, la sicurezza, ...

Per abilitare o disabilitare alcune caratteristiche di Portage, bisogna modificare la variabile FEATURES di /etc/make.conf. In molti casi si devono installare ulteriori tool sui quali sono basate le caratteristiche.

Non sono elencate qui tutte le caratteristiche che Portage supporta. Per una descrizione completa si veda la manpage make.conf:

 

$ man make.conf

Per scoprire quali sono le caratteristiche di default, eseguire emerge info e cercare la variabile FEATURES o eseguire un grep:

 

$ emerge info | grep FEATURES

distcc è un programma per distribuire la compilazione su diverse macchine, non necessariamente identiche, su una rete. Il client distcc trasmette tutte le informazioni necessarie ai server distcc che vengono resi disponibili tramite l'esecuzione di distccd, in modo che possano compilare parte del codice sorgente per il client. Il risultato è un tempo di compilazione inferiore.

E' possibile trovare più informazioni su distcc (e informazioni su come deve funzionare con Gentoo) nella nostra Documentazione Gentoo su distcc.

Distcc include un tool grafico per tenere sotto controllo i task che il computer sta inviando per la compilazione. Se si usa Gnome si inserisca 'gnome' nella variabile USE. Se non si usa Gnome e si desidera comunque utilizzare il monitor, si inserisca 'gtk' nella variabile USE.

 

# emerge distcc

Aggiungere distcc alla variabile FEATURES in /etc/make.conf. Modificare la variabile MAKEOPTS a proprio piacimento. In "-jX" la X è il numero di CPU che eseguono distccd (incluso l'host attuale) più uno, ma si potrebbero avere migliori risultati con altri numeri.

Eseguire distcc-config e impostare la lista di server distcc disponibili. Per esempio si assume che i server distcc disponibili sono 192.168.1.102 (l'host attuale), 192.168.1.103 and 192.168.1.104 (due host remoti):

 

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

Non dimenticarsi di eseguire anche il demone distccd:

 

# rc-update add distccd default
# /etc/init.d/distccd start

ccache è un veloce compilatore di cache. Dopo aver compilato un programma, esso immagazzina i risultati intermedi, in modo che se si dovesse ricompilare lo stesso programma, il tempo di compilazione sia notevolmente ridotto. Nelle compilazioni comuni, il tempo di compilazione risulta di 5-10 volte più veloce.

Per maggiori informazioni su ccache, è possibile consultare la homepage di ccache.

Per installare ccache, eseguire emerge ccache:

 

# emerge ccache

Aprire /etc/make.conf e aggiungere ccache alla variabile FEATURES. Poi, aggiungere una nuova variabile chiamata CCACHE_SIZE e impostarla a "2G":

 

CCACHE_SIZE="2G"

Per controlare se ccache funziona, si possono vedere le statistiche:

 

# ccache -s

Se si desidera usare ccache per compilazioni non-Portage, si aggiunga /usr/lib/ccache/bin all'inizio della variabile PATH (prima di /usr/bin). Può essere fatto modificando /etc/env.d/00basic:

 

PATH="/usr/local/bin:/opt/bin:/usr/lib/ccache/bin"

Portage supporta l'installazione di pacchetti precompilati. Anche se Gentoo non fornisce pacchetti precompilati (tranne GRP), Portage può essere informato dei pacchetti precompilati.

Per creare un pacchetto precompilato si può usare quickpkg se il pacchetto è già installato sul sistema, o emerge con le opzioni --buildpkg o --buildpkgonly.

Se si desidera che Portage crei pacchetti precompilati di ogni singolo pacchetto che si installa, aggiungere buildpkg alla variabile FEATURES.

Supporto più esteso per le impostazioni sui pacchetti precompilati può essere ottenuto con il catalyst. Per ulteriori informazioni sul catalyst leggere Catalyst Reference Manual e Catalyst Howto.

Anche se Gentoo non li fornisce, si può creare un repository centrale dove mettere i pacchetti precompilati. Se si desidera usare questo repository, si deve far puntare la variabile PORTAGE_BINHOST ad esso. Per esempio, se i pacchetti precompilati sono su ftp://buildhost/gentoo:

 

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Quando si desidera installare un pacchetto precompilato, si deve aggiungere l'opzione --getbinpkg al comando emerge accanto all'opzione --usepkg. Il primo (--getbinpkg) dice a emerge di scaricare il pacchetto precompilato dal server precedentemente definito mentre il secondo (--usepkg) chiede a emerge di cercare di installare il pacchetto precompilato prima di scaricare i sorgenti e compilarlo.

Per esempio, per installare gnumeric con i pacchetti precompilati:

 

# emerge --usepkg --getbinpkg gnumeric

Più informazioni sulle opzioni di emerge con i pacchetti precompilati possono essere trovate nella manpage emerge:

 

$ man emerge

All'avvio del sistema, ci sono molte scritte che scorrono e il testo è il medesimo ad ogni avvio. La sequenza di tutte queste azioni viene chiamata boot sequence ed è (più o meno) definita staticamente.

Per prima cosa, il boot loader carica l'imagine del kernel, definita nella configurazione in memoria, dopo di che dice alla CPU di eseguire il kernel. Quando il kernel è caricato e in esecuzione, inizializza la struttura del kernel e i task e avvia il processo init.

Questo processo si assicura che tutti i filesystem (definiti in /etc/fstab) siano montati e pronti per l'uso. Poi esegue alcuni script situati in /etc/init.d, che avviano i servizi necessari per un corretto avvio del sistema.

Alla fine, quando tutti gli scripts sono eseguiti, init attiva i terminali (nella maggior parte dei casi solo le console virtuali che sono nascoste in Alt-F1, Alt-F2, ecc.) attaccandogli un processo chiamato agetty. Questo processo per prima cosa si assicura che sia possibile eseguire il login su questi terminali eseguendo login.

Ora init non esegue gli script in /etc/init.d casualmente. Inoltre, non lancia tutti gli script in /etc/init.d, ma solo quelli che gli è stato detto di eseguire. Decide che script eseguire guardando in /etc/runlevels.

Prima, init esegue tutti gli scripts da/etc/init.d che hanno un link simbolico in /etc/runlevels/boot. Solitamente, esegue gli scripts in ordine alfabetico, ma alcuni scripts hanno delle informazioni di dipendenze all'interno, che dicono al sistema che un altro script deve essere avviato prima che possa essere avviato.

Quando tutti gli script refenziati in /etc/runlevels/boot sono stati eseguiti, init continua eseguendo gli script che hanno un link simbolico in /etc/runlevels/default. Ancora, usa l'ordine alfabetico per decidere che script avviare prima, a meno che lo script non abbia dipendenze, nel qual caso l'ordine viene cambiato per fornire una valida sequenza di boot.

Certamente init non decide tutto da solo. Ha bisogno di un file di configurazione che specifica quali azioni debba eseguire. Questo file di configurazione è /etc/inittab.

La prima azione di init è di montare tutti i filesystems. Questo è definito nella seguente linea di /etc/inittab:

 

si::sysinit:/sbin/rc sysinit

Questa linea dice a initche deve eseguire /sbin/rc sysinit per inizializzare il sistema. Lo script /sbin/rc si occupa dell'inzializzazione, init infatti non fa molto -- esso delega altri task come l'inizializzazione del sistema a un'altro processo.

In secondo luogo init esegue gli scripts che hanno un link in /etc/runlevels/boot. Questo è definito dalla seguente linea:

 

rc::bootwait:/sbin/rc boot

Ancora lo script rc provvede ai task necessari. Notare che l'opzione passata a rc (boot) è la stessa della sottodirectory /etc/runlevels.

Ora init controlla il suo file di configurazione per vedere quale runlevel deve eseguire. Per deciderlo, legge la seguente linea da /etc/inittab:

 

id:3:initdefault:

In questo caso (che la maggioranza di utenti Gentoo usa), l'id del runlevel è 3. Usando questa informazione, init vede che deve avviare il runlevel 3:

 

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

La linea che definisce il livello 3, ancora, usa lo script rc per avviare il servizio (ora con argomento default). L'argomento di rc è ancora lo stesso della sottodirectory in /etc/runlevels.

Quando rc ha finito, init decide quale console virtuale attivare e quali comandi devono essere esguiti su ciascuna 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

Init usa uno schema numerico per decidere quale runlevel attivare. Un runlevel è uno stato nel quale il sistema viene avviato e contiene una collezione di scripts (runlevel script o initscripts) che devono essere eseguiti quando si entra o si lascia un runlevel.

In Gentoo, ci sono sette runlevel definiti: tre runlevel interni, e quattro runlevel definiti dall'utente. I runlevel interni si chiamano sysinit, shutdown ereboot e fanno esattamente quello che i nomi implicano: inizializzano il sistema, spengono il sistema e riavviano il sistema.

I runlevel definiti dall'utente sono delle sottodirectory di /etc/runlevels: boot, default, nonetwork e single. Il runlevel boot avvia tutti i servizi necessari al sistema che tutti gli altri runlevel usano. I rimanenti tre differiscono per i servizi avviati: default viene usato per le operazioni di tutti i giorni, nonetwork è usato in caso non sia necessaria alcuna connettività, e single viene usato per riparare il sistema.

Gli script che il processo rc avvia sono chiamati init script. Ogni script in /etc/init.d può essere eseguito con gli argomenti start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme o broken.

Per avviare, fermare o riavviare un servizio (e tutti i servizi dipendenti), vengono usati start, stop e restart:

 

# /etc/init.d/postfix start

	Nota
	Solo i servizio necessari al servizio dato saranno fermati o riavviati. Gli altri servizi dipendenti (quelli che usa ma non gli sono necessari) non vengono toccati.

Per fermare un servzio, ma non i servizi che dipendono da lui si può usare l'argomento pause:

 

# /etc/init.d/postfix pause

Per vedere un servizio in che stato si trova (started, stopped, paused, ...) si può usare l'argomento status:

 

# /etc/init.d/postfix status

Se le informazioni di stato dicono che un servizio è in esecuzione, ma non è così, si può fare il reset delle informazioni di stato a "stopped" con l'argomento zap:

 

# /etc/init.d/postfix zap

Per sapere quali dipendenze ha un servizio si può usare iuse o ineed. Con ineed vengono mostrati i servizi veramente necessari per il corretto funzionamento del servizio. iuse invece mostra i servizi che vengono usati ma non sono necessari al servizio per il corretto funzionamento.

 

# /etc/init.d/postfix ineed

In modo simile si può chiedere la lista dei servizi che dipendono da lui (needsme) o possono usarlo

 

# /etc/init.d/postfix needsme

Infine, si possono chiedere quali dipendenze che sono mancanti richiede un servizio:

 

# /etc/init.d/postfix broken

Il sistema di init in Gentoo usa un albero di dipendenze per decidere quali dipendenze vanno avviate prima. Essendo un task tedioso da eseguire manualmente c'è un tool che rende semplice l'amministrazione dei runlevel e init scripts.

Con rc-update si possono aggiungere e rimuovere init scripts da un runlevel. Il tool rc-update automaticamente interroga depscan.sh per ricostruire l'albero delle dipendenze.

Lo script rc-update richiede un secondo argomento che definisce l'azione: add, del o show.

Per aggiungere o rimuovere un'init script, bisogna passare a rc-update l'argomento add o del, seguito dallo script di init e dal runlevel. Per esempio:

 

# rc-update del postfix default

Il comando rc-update show mostra tutti gli script init disponibili e in quale runlevel vengono eseguiti:

 

# rc-update show

Gli Init scripts possono essere complessi. Qui non si è interessati a far modificare direttamente gli init script, dato che sono piuttosto proni a errori. E' comunque importante saper configurare bene un servizio. Ad esempio per per dare più opzioni al servizio stesso.

Un secondo motivo è di avere la configurazione al di fuori dell'init script per aggiornare gli init scripts senza preoccuparsi di perdere i cambiamenti alla configurazione.

Gentoo fornisce un modo semplice per configurare i servizi: ogni init script che può esser configurato ha un file in /etc/conf.d. Per esempio, l'init script di apache2 (chiamato /etc/init.d/apache2) ha un file di configurazione chiamato /etc/conf.d/apache2, che contiene le opzioni che volete dare al server Apache 2 quando viene avviato:

 

APACHE2_OPTS="-D PHP4"

I file di configurazione contengono variabili e solo quello (tipo /etc/make.conf), e rendono davvero facile configurare un servizio. Permettono inoltre di aggiungere molte informazioni sulle variabili (come commenti).

No. Scrivere init script non è solitamente necessario dato che Gentoo fornisce init scripts pronti all'uso per ogni servizio. Comunque, si potrebbe installare un servizio senza usare Portage, nel qual caso probabilmente è necessario creare un init script.

E' consigliabile non usare init script forniti dal servizio se non sono scritti esplicitamente per Gentoo: gli init scripts di Gentoo non sono compatibili con gli init scripts usati dalle altre distribuzioni!

Il layout di base di un init script è mostrato sotto.

 

#!/sbin/runscript

depend() {
  (Informazioni di dipendenza)
}

start() {
  (Comando necessario per avviare un servizio)
}

stop() {
  (Comando necessario per fermare un servizio)
}

restart() {
  (Comando necessario per riavviare un servizio)
}

Ogni init script richiede che la funzione start() sia definita. Tutte le altre sezioni sono opzionali.

Ci sono due tipi di dipendenze che possono essere definite: use e need. Come menzionato sopra, la dipendenza need è più restrittiva della dipendenza use. Secondo questo tipo di dipendenza si definisce il concetto di dipendenza virtuale.

Una dipendenza virtual è una dipendenza che fornisce un servizio, ma non è fornita solo da quel servizio. L'init script può dipendere da un system logger, ma ci sono molti system loggers disponibili (metalogd, syslog-ng, sysklogd, ...). Dato che non è possibile mettere need per ognuno di loro (nessun sistema ha tutti questi system loggers installati e in esecuzione) ci si assicura che tutti questi servizi forniscano una dipendenza virtuale.

 

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

Il servizio postfix:

In alcuni casi si potrebbe non aver bisogno di un servizio, ma si può voler avviare un servizio prima (o dopo) un'altro se disponibile sul sistema (notare il condizionale - questa non è un'altra dipendenza) e eseguirle nello stesso runlevel. Si possono fornire queste informazioni usando before o after.

 

depend() {
  need net
  before inetd
  before xinetd
}

Si può anche usare "*" per selezionare tutti i servizi nello stesso runlevel, ma non è consigliabile.

 

depend() {
  before *
}

Dopo la funzione depend(), è necessario definire la funzione start(). Questa contiene tutti i comandi necessari ad inizializzare il servizio. E' consigliabile usare le funzioni ebegin e eend per informare l'utente su cosa sta accadendo:

 

start() {
  ebegin "Starting my_service"
  start-stop-daemon --start --quiet --exec /path/to/my_service
  eend $?
}

Per maggiori esempi sulla funzione start(), si possono leggere i sorgenti degli init script disponibili in /etc/init.d. Per start-stop-daemon, è disponibile un'eccellente man page per maggiori informazioni:

 

# man start-stop-daemon

Altre funzioni che si possono definire sono: stop() e restart(). Non si è obbligati a definire queste funzioni! Il sistema di init è abbastanza intelligente da inserire da solo queste funzioni se si usa start-stop-daemon.

Se si ha bisogno di maggiori opzioni negli init script, si può aggiungere l'opzione alla variabile opts, e creare una funzione con lo stesso nome dell'opzione. Per esempio, per il supporto di un'opzione chiamata restartdelay:

 

opts="${opts} restartdelay"

restartdelay() {
  stop()
  sleep 3    # Wait 3 seconds before starting again
  start()
}

Non c'è bisogno di aggiungere un file di configurazione in /etc/conf.d: se l'init script è eseguito, vengono automaticamente processati i seguenti file (i.e. the variables are available to use):

Inoltre, se l'init script fornisce una dipendenza virtuale (come net), viene processato anche il file associato a questa dipendenza (come /etc/conf.d/net).

Molti utenti di portatili conoscono la situazione: a casa si ha bisgno di avviare net.eth0 ma non si vuole avviare net.eth0 quando si è per strada (se non c'è nessuna rete disponibile). Con Gentoo si può alterare il comportamento del runlevel per venire incontro alle proprie esigenze.

Per esempio si può creare un secondo "default" runlevel nel quale eseguire il boot che altri init scripts assegnati. Si può selezionare al momento del boot quale defalt runlevel usare.

Per prima cosa, si crea la directory di runlevel per il secondo "default" runlevel. Per esempio per creare il runlevel offline:

 

# mkdir /etc/runlevels/offline

Aggiungere i necessari init scripts al nuovo runlevel creato. Per esempio, per avere una copia del corrente runlevel default ma senza net.eth0:

 

# ls /etc/runlevels/default
acpid  domainname  local  net.eth0  netmount  postfix  syslog-ng  vixie-cron
# rc-update add acpid offline
# rc-update add domainname offline
# rc-update add local offline
# rc-update add syslog-ng offline
# rc-update add vixie-cron offline

Ora bisogna configurare il bootloader e aggiungere una nuova voce per il runlevel offline. Per esempio in /boot/grub/grub.conf:

 

title Gentoo Linux Offline Usage
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Se per il boot del sistema si seleziona la nuova voce il runlevel offline viene usato al posto del default.

Usare bootlevel è completamente analogo a softlevel. L'unica differenza è che si sta definendo un secondo runlevel di "boot" invece di un secondo runlevel "default".

Una variabile ambiente è un oggetto nominale che contiene informazioni usate da una o più applicazioni. Questo viene trovato un po' misterioso o di difficile gestione da parte di molti utenti, specialmente coloro che si avvicinano per la prima volta a Linux. L'uso di variabili ambiente, invece, può facilitare la modifica della configurazione per una o più applicazioni.

Segue una tabella con la lista delle variabili usate su un sistema Linux e la loro descrizione. I valori di esempio sono presentati di seguito.

Segue un esempio di definizione di tutte queste variabili:

 

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"
CLASSPATH="/opt/blackdown-jre-1.4.1/lib/rt.jar:."
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

Per centralizzare la definizione di queste variabili, è stata introdotta in Gentoo la directory /etc/env.d. All'interno di questa directory si trovano un certo numero di file, come 00basic, 05gcc, ecc. che contengono le variabili necessarie alle applicazioni menzionate nel nome del file.

Per maggiore chiarezza; quando si installa il gcc, viene anche creato dall'ebuild un file chiamato 05gcc, che contiene la definizione delle seguenti variabili:

 

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"

In altre distribuzioni la definizione di variabili ambiente viene fatta con modifiche o aggiunte al file /etc/profile o ad altre locazioni. D'altra parte l'uso di Gentoo facilita la manutenzione e la gestione delle variabili ambiente, dato che non occorre fare attenzione ai numerosi file che possono contenere variabili ambiente.

Per esempio, durante l'aggiornamento del gcc viene anche aggiornato il file /etc/env.d/05gcc senza nessuna richiesta di interazione da parte dell'utente.

Di questo sono beneficiari il Portage e anche l'utente. Occasionalmente potrebbe nascere l'esigenza di configurare una variabile ambiente a livello globale. Prendiamo per esempio la variabile http_proxy. Invece di modificare l'/etc/profile, basta creare un file /etc/env.d/99local, e inserire la seguente definizione:

 

http_proxy="proxy.server.com:8080"

L'uso dello stesso file per tutte le variabili utente, aiuta ad avere una panoramica delle variabili definite in seguito dall'utente stesso.

Alcuni file in /etc/env.d definiscono la variabile PATH. L'esecuzione di env-update appende le diverse definizioni prima di aggiornare le varabili ambiente, rendendo semplice l'aggiunta di variabili ambiente ai pacchetti (o agli utenti) senza interferire con i valori già presenti.

Lo script env-update appende i valori dei file in /etc/env.d in ordine alfabetico. Questo è il motivo per cui i nomi dei file in /etc/env.d iniziano con un numero.

 

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

Durante l'esecuzione di env-update vengono create tutte le variabili ambiente e verranno poste in /etc/profile.env (usato a sua volta da /etc/profile). Vengono inoltre estratte le informazioni dalla variabile LDPATH per creare il file /etc/ld.so.conf. Dopo di che, viene eseguito il comando ldconfig per ricreare il file /etc/ld.so.cache usato dal linker dinamico.

Per vedere l'effetto immediato di env-update dopo il suo uso, eseguire il seguente comando per aggiornare l'ambiente. Utenti che hanno installato Gentoo, si ricordano probabilmente questo dalle istruzioni di installazione:

 

# env-update && source /etc/profile

Non sempre è conveniente definire variabili ambiente a livello globale. Per esempio, l'aggiunta di /home/mioutente/bin alla variabile PATH non dovrebbe riflettersi su tutti gli altri utenti. E' necessario definire una variabile ambiente locale e per questo occorre usare i file ~/.bashrc o ~/.bash_profile:

 

PATH="${PATH}:/home/mioutente/bin"

Dopo un nuovo login, la variabile PATH viene aggiornata.

A volte sono necessarie anche definizioni più ristrette. Potrebbe essere il caso in cui è necessario usare file binari di una directory temporanea senza usare il percorso dei binari di sistema o senza editare ~/.bashrc per la temporaneità dell'uso.

In questo caso si può definire la variabile PATH nella sessione corrente usando il comando export. Finché non si esegue un'operazione di logout, la variabile PATH manterrà la configurazione temporanea.

 

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

Autore: Sven Vermeulen

Autore: Daniel Robbins

Autore: Chris Houser

Autore: Jerry Alexandratos

Sviluppo x86: Seemant Kulleen

Sviluppo Alpha: Tavis Ormandy

Sviluppo Alpha: Aron Griffis

Sviluppo AMD64: Jason Huebel

Sviluppo HPPA: Guy Martin

Sviluppo PPC: Pieter Van den Abeele

Sviluppo SPARC: Joe Kallar

Redazione: John P. Davis

Redazione: Pierre-Henri Jondot

Redazione: Eric Stockbridge

Redazione: Rajiv Manglani

Redazione: Jungmin Seo

Redazione: Stoyan Zhekov

Redazione: Jared Hudson

Redazione: Colin Morey

Redazione: Jorge Paulo

Redazione: Carl Anderson

Redazione: Jon Portnoy

Redazione: Zack Gilburd

Redazione: Jack Morgan

Redazione: Benny Chuang

Redazione: Erwin

Redazione: Joshua Kinard

Redazione: Tobias Scherbaum

Revisione: Grant Goodyear

Revisione: Gerald J. Normandin Jr.

Revisione: Donnie Berkholz

Revisione: Ken Nowack

Contributi: Lars Weiler

Traduzione: Marco Mascherpa

Traduzione: Stefano Rossi

Traduzione: Enrico Morelli