Gentoo Logo

Disclaimer : Questo manuale è stato sostituito da una nuova versione e non è più mantenuto.


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


1. Una introduzione di Portage

Indice:

1.a. Benvenuti in Portage

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:

Codice 1.1: Leggere la pagina man di emerge

# man emerge

1.b. L'albero del Portage

Gli ebuild

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.

Aggiornamento dell'albero del Portage

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:

Codice 2.1: Aggiornamento dell'albero del Portage

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

Codice 2.2: Eseguire emerge-webrsync

# emerge-webrsync

Un vantaggio ulteriore nell'uso di emerge-webrsync è che consente all'amministratore di prelevare nel portage solo gli snapshot dell'albero che sono contrassegnati dalla chiave GPG dela Gentoo release engineering. Ulteriori informazioni su questo argomento possono essere trovate nella sezione Prelevare snapshot del portage convalidati, di Caratteristiche di Portage.

1.c. Manutenzione del software

Ricerca del software

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:

Codice 3.1: Cercare i pacchetti che contengono pdf nel nome

$ emerge --search pdf

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

Codice 3.2: Cercare i pacchetti che contengono pdf nella descrizione

$ emerge --searchdesc pdf

Da uno sguardo all'output si nota che vengono fornite diverse informazioni. I campi sono chiaramente identificativi per cui non si addentrerà ulteriormente nel loro significato:

Codice 3.3: Esempio dell'output di 'emerge --search'

*  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

Installazione del software

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:

Codice 3.4: 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:

Codice 3.5: Fingere di installare gnumeric

# 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 estratto, compilato ed installato. Se si vuole che Portage scarichi solo i sorgenti senza installarli, aggiungere al comando emerge l'opzione --fetchonly:

Codice 3.6: Scaricare il codice sorgente di gnumeric

# emerge --fetchonly gnumeric

Trovare la documentazione di pacchetti installati

Molti pacchetti forniscono la propria documentazione. Alcune volte il flag USE doc determina se la documentazione del pacchetto verrà installata o no. Si può controllare l'esistenza di un flag USE doc con il comando emerge -vp <nome pacchetto>.

Codice 3.7: Controllo dell'esistenza di un flag USE doc

(Naturalmente, alsa-lib è solamente un esempio.)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.14_rc1  -debug +doc 698 kB

La modalità di abilitazione migliore per la flag USE doc è quella per singolo pacchetto tramite /etc/portage/package.use, in modo da avere la documentazione solo per i pacchetti desiderati. Abilitare globalmente questa flag può introdurre dei problemi di dipendenze circolari. Per maggiori informazioni, si prega di consultare il capitolo Flag USE.

Una volta che il pacchetto è stato installato, la sua documentazione viene generalmente trovata in una sottodirectory col nome del pacchetto nella directory /usr/share/doc. Si può avere la lista dei file installati con lo strumento equery che fa parte del pacchetto app-portage/gentoolkit .

Codice 3.8: Trovare la documentazione di un pacchetto

# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1
total 28
-rw-r--r--  1 root root  669 May 17 21:54 ChangeLog.gz
-rw-r--r--  1 root root 9373 May 17 21:54 COPYING.gz
drwxr-xr-x  2 root root 8560 May 17 21:54 html
-rw-r--r--  1 root root  196 May 17 21:54 TODO.gz

(Alternativamente, usare equery per localizzare file che interessano:)
# equery files alsa-lib | less
media-libs/alsa-lib-1.0.14_rc1
* Contents of media-libs/alsa-lib-1.0.14_rc1:
/usr
/usr/bin
/usr/bin/alsalisp
(output troncato)

Rimozione del software

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.

Codice 3.9: Rimozione di gnumeric

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

Aggiornare il software

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. Nell'esempio che segue, verrà utilizzato il parametro --ask che istruisce il Portage a visualizzare la lista dei pacchetti da aggiornare e la richiesta se si vuole continuare:

Codice 3.10: Aggiornare il sistema

# emerge --update --ask world

Portage cercherà quindi le nuove versioni delle applicazioni installate. Verranno comunque verificate solo le versioni per le applicazioni che si sono esplicitamente installate (cioè le applicazioni elencate in /var/lib/portage/world) e non le dipendenze. Se si vogliono aggiornare anche le dipendenze di questi ultimi pacchetti, occorre aggiungere l'argomento --deep:

Codice 3.11: Aggiornare il sistema con le dipendenze

# emerge --update --deep world

Questo ancora non vuol dire tutti i pacchetti: alcuni pacchetti nel proprio sistema sono necessari durante le fasi di compilazione e assemblaggio di altri pacchetti, ma una volta che questi sono installati, questi pacchetti non sono più necessari. Portage chiama queste dipendenze di assemblaggio. Per includerle in un ciclo di aggiornamento, occorre aggiungere --with-bdeps=y:

Codice 3.12: Aggiornare l'intero sistema

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

Dato che aggiornamenti che riguardano la sicurezza possono essere correlati a pacchetti che non si sono esplicitamente installati nel sistema (ma che sono stati installati quali dipendenze di altri programmi), si raccomanda di eseguire questo comando una volta ogni tanto.

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:

Codice 3.13: Eseguire un aggiornamento completo

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

Metapacchetti

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-meta 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:

Codice 3.14: Rimozione delle dipendenze orfane

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

revdep-rebuild viene fornito col pacchetto gentoolkit, che deve essere quindi preventivamente installato:

Codice 3.15: Installazione del pacchetto gentoolkit

# emerge gentoolkit

1.d. Licenze

A partire dalla versione 2.1.7 di Portage, è possibile accettare o rifiutare l'installazione di un software in base alla sua licenza. Tutti i pacchetti nell'albero di Portage contengono una voce LICENSE nelle rispettive ebuild. Eseguendo emerge --search nomepacchetto è possibile visualizzare la licenza del pacchetto.

Come impostazione predefinita, Portage permette tutte le licenze, eccetto le "End User License Agreements" (EULA) che richiedono la lettura e la sottoscrizione dell'accettazione di un accordo.

La variabile che controlla le licenze permesse è ACCEPT_LICENSE, che può essere impostata in /etc/portage/make.conf:

Codice 4.1: Valorizzazione predefinita di ACCEPT_LICENSE in /etc/portage/make.conf

ACCEPT_LICENSE="* -@EULA"

Con questa configurazione, i pacchetti che richiedono un'interazione durante l'installazione a causa dell'approvazione della loro licenza EULA non verranno installati. I pacchetti senza un licenza di tipo EULA verranno installati.

È possibile specificare globalmente ACCEPT_LICENSE all'interno di /etc/portage/make.conf, o specificarla in base ad ogni pacchetti in /etc/portage/package.license.

Per esempio, se si vuol permettere la licenza truecrypt-2.7 per app-crypt/truecrypt, aggiungere la voce seguente al file /etc/portage/package.license:

Codice 4.2: Specificare una licenza truecrypt in package.license

app-crypt/truecrypt truecrypt-2.7

Questo permette l'installazione delle versioni di truecrypt che hanno una licenza truecrypt-2.7, ma non delle versioni che hanno una licenza truecrypt-2.8

Importante: Le licenze sono memorizzate all'interno della directory /usr/portage/licenses, e i gruppi di licenze dentro a /usr/portage/profiles/license_groups. La prima voce di ogni linea avente lettere MAIUSCOLE è il nome del gruppo delle licenze, e ogni voce successiva è una licenza individuale.

I gruppi di licenze definiti in ACCEPT_LICENSE hanno il prefisso @ nel loro nome. Ecco un esempio di un sistema che permette globalmente il gruppo di licenze compatibile con GPL, oltre ad alcuni altri gruppi e singole licenze :

Codice 4.3: ACCEPT_LICENSE in /etc/portage/make.conf

ACCEPT_LICENSE="@GPL-COMPATIBLE @OSI-APPROVED @EULA atheros-hal BitstreamVera"

Se nel proprio sistema si vogliono solamente documentazione e software libero, è consigliabile usare la seguente impostazione:

Codice 4.4: Usare solo licenze libere

ACCEPT_LICENSE="-* @FREE"

In questo caso, "free" ("libero", ndt) viene solitamente definito da FSF e OSI. Qualsiasi pacchetto la cui licenza non soddisfi tali requisiti non potrà essere installata nel proprio sistema.

1.e. Errori durante l'uso del Portage

Slot, virtuals, branche, architetture e profili

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 virtuals: ogni logger di sistema è elencato come dipendenza "esclusiva" del servizio di loggind nel pacchetto virtuale logger della categoria virtual, quindi queste applicazioni dipendono dal pacchetto virtual/logger. Una volta installato, il pacchetto tirerà il primo pacchetto menzionato nello stesso, a meno che non sia già installato.(In questo caso il virtual è soddisfatto).

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.

Pacchetti bloccati

Codice 5.1: Portage avverte riguardo ai pacchetti bloccati (con --pretend)

[blocks B     ] mail-mta/ssmtp (from pkg mail-mta/postfix-2.2.2-r1)

Codice 5.2: Portage avverte riguardo ai pacchetti bloccati (senza --pretend)

!!! Error: the mail-mta/postfix 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.

Sebbene le versioni recenti di Portage siano sufficentemente avanzate nel risolvere dei semplici blocchi senza l'intervento dell'utente, occasionalmente bisognerà correggerli manualmente, come spiegato qui di seguito.

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 postfix o rimuovere prima ssmtp.

Si possono anche avere blocchi a livello di versione del pacchetto, come <media-video/mplayer-1.0_rc1-r2. In questo caso, l'aggiornamento ad una versione più recente potrebbe essere sufficiente a rimuovere il blocco.

E' anche possibile che due pacchetti che devono essere ancora installati siano in conflitto tra loro. In questo raro caso, si dovrebbe capire perché si vogliono installare entrambi dato che in molti casi può bastare l'installazione di un solo pacchetto. Se non è questo il caso, aprire un bug sul Gentoo bugtracking system.

Pacchetti mascherati

Codice 5.3: Portage avverte riguardo ai pacchetti mascherati

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

Codice 5.4: Portage avverte riguardo ai pacchetti mascherati - la ragione

!!! 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)
- 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 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:

  • ~arch keyword significa che l'applicazione non è stata sufficientemente testata per essere inserita nella branca stabile. Aspettare alcuni giorni o alcune settimane e provare nuovamente.
  • -arch keyword o -* keyword significa che l'applicazione non funziona sulla nostra architettura. Se si crede che il pacchetto funzioni, aprire un bug sul bugzilla di Gentoo.
  • missing keyword significa che l'applicazione non è ancora stata testata sulla nostra architettura. Chiedere al gruppo che si occupa del porting per l'architettura di testare il pacchetto o testarlo per loro e riportare i risultati sul bugzilla di Gentoo.
  • package.mask significa che il pacchetto è corrotto, instabile o difettoso ed è stato deliberatamente marcato come non-usare.
  • profile significa che il pacchetto non è stato trovato appropriatamente nel vostro profilo. Le applicazioni potrebbero danneggiare il sistema se installate o sono solo non compatibili col profilo in uso.
  • license significa che la licenza del pacchetto non è compatibile con la propria impostazione di ACCEPT_LICENSE. bisogna esplicitamente permettere la licenza o il gruppo nel quale essa è contenuta inserendola in /etc/portage/make.conf o in /etc/portage/package.license. Fare riferimento alla sezione Licenze per ricevere ulteriori informazioni sul loro funzionamento.

Modifiche necessarie alle flag USE

Codice 5.5: Avvisi del Portage sulla richiesta di modifica di flag USE

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

Se --autounmask non è impostato, il messaggio di errore può essere anche mostrato come segue:

Codice 5.6: Errore del Portage sulla richiesta di modifica di flag USE

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Questi messaggi appaiono quando si vuole installare un pacchetto che non solo dipende da un altro pacchetto, ma richiede anche che quel pacchetto sia compilato con una particolare flag USE (o insieme di flag USE). Nell'esempio proposto, il pacchetto app-text/feelings ha bisogno di essere compilato con USE="test", ma questa flag USE non impostata nel sistema.

Per risolvere, si può o aggiungere la flag USE alle flag USE globali in /etc/portage/make.conf o impostarla per il pacchetto specifico in /etc/portage/package.use.

Dipendenze omesse

Codice 5.7: Portage avverte riguardo le dipendenze omesse

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.

Nomi di ebuild ambigui

Codice 5.8: Portage avverte circa l'ambiguità di nomi di ebuild

[ Results for search key : listen ]
[ Applications found : 2 ]

*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD

*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2

!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

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

Dipendenze circolari

Codice 5.9: Portage avverte circa le dipendenze circolari

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

Scaricamento non riuscito

Codice 5.10: Portage avverte circa un download non riuscito

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

Protezione dei profili di sistema

Codice 5.11: Portage avverte circa la protezione dei profili

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

Insuccessi nella verifica del digest

A volte durante il tentativo di emergere un pacchetto, si ottiene un errore col seguente messaggio:

Codice 5.12: Insuccesso di verifica del digest

>>> checking ebuild checksums
!!! Digest verification failed:

Questo è un segno che c'è qualche cosa di errato nell'albero del Portage. Spesso è causato da uno sviluppatore che può aver sbagliato l'inserimento del pacchetto nell'albero del Portage.

Quando la verifica del digest fallisce, non provare a ricreare il digest. Eseguire ebuild foo manifest non risolve il problema, ma molto probabilmente lo peggiorerà!

Il suggerimento è di aspettare un'ora o due perché venga sistemato l'albero del Portage. E' probabile che l'errore sia già stato notato, ma occorre un po' di tempo affinché la correzione sia diramata. Durante l'attesa, controllare su Bugzilla per vedere se qualcuno ha riportato il problema. In caso contrario segnalare il bug per il pacchetto oggetto del problema.

Una volta controllato che il bug sia stato corretto, provare ad eseguire nuovamente il sync per ottenere il digest corretto.

Importante: Questo non significa che si possa fare un sync tre volte di seguito! Come specificato nella politica di rsync (visibile quando si esegue emerge --sync), gli utenti che eseguono sync troppo spesso verranno interdetti. Infatti è meglio aspettare il prossimo sync che si è schedulato per evitare il sovraccarico dei server rsync.


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


Stampa

Visualizza tutto

Aggiornato il 15 agosto 2012

Questa traduzione non è più mantenuta

Oggetto: Questo capitolo spiega i semplici passi che un utente deve conoscere per mantenere il software sul proprio sistema.

Sven Vermeulen
Autore

Grant Goodyear
Autore

Roy Marples
Autore

Daniel Robbins
Autore

Chris Houser
Autore

Jerry Alexandratos
Autore

Seemant Kulleen
Sviluppo x86

Tavis Ormandy
Sviluppo Alpha

Jason Huebel
Sviluppo AMD64

Guy Martin
Sviluppo HPPA

Pieter Van den Abeele
Sviluppo PPC

Joe Kallar
Sviluppo SPARC

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
Redazione

Lars Weiler
Redazione

Jochen Maes
Redazione

Xavier Neys
Redazione

Joseph Jezak
Redazione

Joshua Saddler
Redazione

Gerald J. Normandin Jr.
Revisione

Donnie Berkholz
Revisione

Ken Nowack
Revisione

Marco Mascherpa
Traduzione

Stefano Pacella
Traduzione

Enrico Morelli
Traduzione

Davide Cendron
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.