Handbook:Parts/Working/Portage/it

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Handbook:Parts/Working/Portage and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎polski • ‎português do Brasil • ‎čeština • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어
Manuale Parts
Installazione
Riguardo l'installazione
Il mezzo d'installazione
Configurare la rete
Preparare i dischi
Installare lo stage3
Installare il sistema base
Configurare il kernel
Configurare il sistema
Strumenti di sistema
Configurare l'avviatore
Ultimare l'installazione
Lavorare con Gentoo
Introduzione a Portage
Opzioni USE
Funzionalità di Portage
Sistema script di init
Variabili d'ambiente
Lavorare con Portage
File e cartelle
Variabili
Mixare i rami del software
Strumenti aggiuntivi
Repositorio pacchetti personalizzato
Funzionalità avanzate
Configurare la rete
Come iniziare
Configurazione avanzata
Networking modulare
Wireless
Aggiungere funzionalità
Gestione dinamica


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

Un vantaggio aggiuntivo quando si usa emerge-webrsync consiste nel permettere all'amministratore di scaricare solo le istantanee del repositorio di Gentoo firmate con la chiave GPG dell'ingegneria dei rilasci di Gentoo. Per ulteriori informazioni, consultare le sezioni che trattano le caratteristiche di Portage su Istantanee convalidate del repository di Gentoo.

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

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.

Attenzione
Portage non controllerà se il pacchetto da rimuovere è richiesto da un altro pacchetto. Tuttavia avvertirà l'utente quando un pacchetto importante viene rimosso e potenzialmente danneggia il sistema.
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:

root #emerge --update --ask @world

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

Ciò non significa ancora tutti i pacchetti: alcuni pacchetti nel sistema sono necessari durante la compilazione e la costruzione di altri pacchetti, ma una volta che il pacchetto viene installato, queste dipendenze non sono più necessarie. Portage le chiama dipendenze di costruzione. Per includerle in un ciclo di aggiornamento, aggiungere --with-bdeps=y:

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

Poiché gli aggiornamenti di sicurezza capitano anche per i pacchetti non esplicitamente installati nel sistema (ma tirati dentro come dipendenze di altri programmi), è raccomandato eseguire questo comando una volta ogni tanto.

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

revdep-rebuild è fornito dal pacchetto app-portage/gentoolkit; non dimenticarsi di installarlo:

root #emerge --ask app-portage/gentoolkit

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.

Important
The LICENSE variable in an ebuild is only a guideline for Gentoo developers and users. It is not a legal statement, and there is no guarantee that it will reflect reality. So don't rely on it, but check the package itself in depth, including all files that you use.

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.

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)
CODE Avvertimento di Portage riguardo i pacchetti bloccati (con --pretend)
!!! Errore: il pacchetto mail-mta/postfix è in conflitto con un altro pacchetto.
!!!        non possono essere installati insieme sullo stesso sistema.
!!!        Usare 'emerge --pretend' per stabilire cosa lo sta bloccando.

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